What is a User Story?

User stories are the basic components of work that are completed in iteration by agile teams. User stories contain part of desired functionality and are written from the user’s perspective. A user story is a short & simple description of the work to be completed in an Iteration and is usually written in simple English. User Stories are always written from the user’s perspective.

Thus, these User Stories help the agile teams to understand the Customer or user perspective and help the team to deliver better incremental value.

Many agile experts believe that user stories are the basic components of a product that can eventually result in a fully developed functionality for the final user.

Every user story needs to be developed with the target audience in mind, with the intention of being easily understood and updated as the project develops. Groups of stories are called Features in the SAFe world. A group of features can constitute either Capabilities or Solutions or Epics in the SAFe.

Since User stories are very brief, they are expected to have the ‘JUST RIGHT’ information, which means User Stories need to contain the right information which should not be TOO LESS or TOO MUCH… User Story should have information that helps the agile teams to build it in the right way.

Who writes the User Stories?

Initially, the Product Owner in the Agile Team starts writing the User Stories, then he needs to include the Agile teams in writing the User Stories. Over a period, Agile teams should start writing the User Stories with the Product owner helping them in clarifying the queries if any.

This helps the team to understand what is expected by the Customer, and how are they going to build it. Drafting the User Story helps the agile team to analyze, and discuss the functionality to be built and consider any risks or impediments in building the User story.

User stories form the Team Backlog.
Who Owns the User Stories in SAFe

POs own the user stories in SAFe and POs are the content authority for the User Stories. Once the stories are developed by the Agile teams, it is the Product Owner or PO who should be accepting the story based on the Acceptance Criteria decided for that story.

The standard format of writing the User Stories

The standard format of writing the user story has the short description and acceptance criteria as follows:

As a (user role / User Persona),
I want to (activity),
So that (business value)

As [user persona],
I want to [do this activity]
So that [accomplish this objective]

Acceptance Criteria

Should validate whether the objective is met by developing a User story

As a – this is from users’ perspective who would be using the functionality
I want – What is the user expecting out of this story
So that – what is achieved by the user

Users need not be the end customer always, Sometimes, the User can be a system (media devices/servers) or device (Printer/robot/PlayStation, etc.)

The agile team should always INVEST in a story. Make sure the stories are satisfying the INVEST principle

I – Independent
N – Negotiable
V – Valuable
E – Estimable
S – Small
T – Testable

The features of a good user story are:

Written in a way that the agile team can easily understand.
Concise enough that it can fit within an Iteration
Specific enough to outline small parts of functionality that can be implemented over the course of a few days or weeks i.e., the length of one iteration.
Story satisfying the INVEST Principle

All team members involved with the business side of the project (sales managers, marketers, a product owner, etc.) write user stories, as this gives us the opportunity to view the future app from the viewpoint of each potential consumer type.

User story writing guide

A good user story can help a developer understand what needs to be done. The process of developing user stories may be broken down into a few simple steps.

Validate the User Requirements
Create Epics
Explain what it means to be “done” or “completed.”
Outline subtasks or tasks
Specify your profiles. Never underestimate the importance of thorough analysis.
Create stories with a Simple Language
Defining Acceptance Criteria
Consider feedback

Real-world examples of user stories

To facilitate planning and discussion, user stories are commonly recorded on index cards or sticky notes, collected in a box, and then arranged on walls or tables. One advantage of agile user stories is that they may be written with varying degrees of specificity. We can write to cover extensive functionality. These extensive types are typically referred to as epics. Here are some real-world user stories examples that might look like.

User Story Example 1:

As a mobile Subscriber, I want to see the pie chart of my account’s data usage
So that I know how much data I have been left with.

Acceptance Criteria:

Users should be able to see the option of ‘pie chart’ in the mobile app.
When clicked on ‘pie chart’, a pie graph should be displayed with the data usage of the user.
The pie chart should display the Used data and the data the remaining data left as on date.
The time range of the data displayed in the pie chart should be for the current month.

User Story Example 2:

As a Mobile Data Subscriber, I want to know how many local text messages I have used
So that I get to understand how many local text messages am left with

Acceptance criteria

Upon signing in, the user should be presented with a chart that graphically contrasts their current data usage with the data plan to which they have subscribed.
Pop-ups of the relevant usage statistics should appear when the subscriber hovers over specific parts of the chart.
The system must show the rest of the data next to the chart.

User Story Example 3:

As a Tourist, I want to see all the attractions surrounding my hotel depicted on a map with pins
so that it is easy for me to identify the sort of attraction.

Acceptance criteria

When the user chooses to see what’s close by, they should be shown a map that they can zoom in or out on.
The map’s pins should be color-coded according to the sort of adjacent destination, such as yellow for restaurants, green for parks, and blue for theatres and concert halls.
A big black pin must be used to show where the hotel is.
A pop-up window with the location’s name, hours, star rating, and phone number should appear when the user hovers over a map pin.

User Story Example 4:

As a Commuter, I want to book the taxi
So that I reach my office on time

Acceptance Criteria:

Commuters should be able to book taxis through the taxi app with their login credentials.
Commuter should be able to select the taxi which reaches his pickup location in less than 5 minutes
Commuter should be able to select the type of vehicle he desires within the list of vehicles displayed in the app.

User Story Example 5:

As a Taxi Driver, I want to cancel the taxi booking
So that I don’t travel too far to pick up the commuter

Acceptance Criteria:

Taxi Driver should be able to see the pick-up point of the commuter to whom he has been assigned.
Taxi drivers should be able to cancel the trip if the commuter’s pick point is beyond 5 km.
Taxi drivers’ reasons of long distance pick up should be listed in ‘reason for canceling’
The taxi drivers should be able to see the message on canceling.
No charge should be levied on to Taxi driver as well customer.
The taxi driver should be able to receive the next booking,

Overly Constrained User Story Example:

As a People manager. I want to see all the tasks that have been allocated to the project, as well as the tasks that have not yet been assigned, as well as the tasks that are presently being worked on,
so that I may better manage the deliverables associated with my project.

Acceptance criteria

Confirm that the project manager has access to an overview screen for each of their projects. The overview panel must provide the project name, allocated tasks, unassigned tasks, activities in progress, and tasks under review.
Make sure that each task shows the username and image of the team member who oversees it.
Upon clicking the assigned user, the user’s profile should open in a new tab. The system must label unassigned jobs with “unassigned” and display a generic user avatar.
Ensure each task category lists its total number of tasks.

The above story is considered Overly constrained because it has too many details, we should not be writing such user stories, User stories should be simple and easy to understand. The above user story should be decomposed into multiple user stories to make it a Just right User story.

Advantages of user stories

Working with user stories has major benefits that have been proven effective. Listed below are many of the primary reasons why many agile teams prioritize user stories:

They’re useful for segmenting expansive product goals into more manageable feature sets.
Prioritized Agile user stories are great for assisting teams in choosing which features to develop first.
User story Acceptance Criteria provide testing criteria for agile teams.
Prioritize work to maximize profit
This facilitates a more creative and adaptable dialogue between the development and design teams.
Brings in user personas to address the role-specific requirements.

Writing user story examples will undoubtedly be an essential activity in the agile way of working through iterations. Emphasize must be the creation of quality user stories. Stories should have Just the right information and be easily readable.

The SAFe POPM Course is one of the role-specific training that will be given to Product Owners and Product Managers to understand what SAFe is and what would be their Roles and responsibilities within SAFe. Also, how to write User stories, what is the importance of writing stories, high-level estimation of user stories, etc. would be discussed with appropriate User Story Examples.