What is User Story – Learn How to Create Good User Stories.

Almost all the Scrum teams I have worked with use “User Stories.” However, most of them are unaware of the origin of “User Story,” All of them think that user story is a “requirement.” In a sense, it could be correct, but that’s not what a User Story is.

What is a User Story?

In the simplest terms, a User Story is a way to express requirements. When a requirement/ functionality is described from the perspective of the user of the product or system or software, it is termed as a User Story.

A user story defines who the user is, what they want, and why they want it. It helps shift the emphasis from a technical requirement to a focus on user value, ensuring the team is aligned on what they are creating and why. It conveys the user's “voice”.

User stories keep software development focused on delivering true and legitimate value. They are often generated through conversations and are based on the INVEST model (Independent, Negotiable, Valuable, Estimable, Small, Testable) for simplicity and effectiveness.

In the old days, developers used to scribble user stories on sticky note pads or colored cards or some other way to structure the conversation. Today, you can easily generate user stories through a site or app like Trello, Jira, Asana, Miro, etc. 

User stories will be captured in everyday language and will be free of technical jargon. Each user story will consist of 10-15 words in length.

The following will guide you to define the user story incrementally:

• Begin with a rough definition of the user story that consists of three key components: The user role, the feature being requested, and the benefit of that feature. 

• Establish the initial acceptance criteria for the user story to be considered finished. 

• Add the user story to the product backlog with a priority assigned to it based on importance and value. 

• In the sprint planning meeting, deconstruct the story into smaller tasks that can be completed within the sprint or at the end of the sprint. 

• Work with the product owner, developers, and relevant stakeholders to clarify details of the user story. Discuss any possible challenges with the implementation of the user story, clarify any requirements, and update acceptance criteria as required upon revamping feedback. 

• Start to work on the user story in iterations. 

• Gain feedback from the stakeholders and end-users to further adapt the user story. 

• When the user story is complete to the definition of done, review the outcome in a sprint retrospective.

A Brief History and Origins of User Stories

User Story or just Stories originated with Extreme Programming. In his book “Extreme Programming Explained” Kent Beck describes Stories as a primary practice used by the XP team. Within XP, the User Stories are written by the Customers as the functions or features that they want the system/software to do for them. It is often in the format of three sentences written by the Customer. The User Story always focuses on the benefits and needs of the user. Keeps the details like technology or implementation aspects out of it.

The User Story Template

In most teams that I have worked with, User Stories are not one-liners, as I expressed above. They have a very specific syntax as follows: 

Example:  As a book lover, I want to read book reviews so that I can decide to purchase a book. This template was invented at Connextra, an early adopter of XP practices (source: User Stories Applied, Mike Cohn).

Examples of User Stories

Let’s break down the ins and outs of an agile user story from an end user’s perspective. Here are some examples: 

Product: A Food Delivery app

User Story Example 1:

As a user who has decided what to order, I want to proceed to checkout so that I can complete my order and have my food delivered to me.

User Story  Example  2: 

As a user who has placed an order, I want to schedule my delivery time so that I can choose a time for the food to be delivered when it works best with my schedule.

User Story  Example 3:

As a user, I want to see my order history so that I can easily reorder my previous orders or keep track of what I ordered before.

User Story Example 4: 

As a customer, I want to view my food order in real time so that I know when to expect my delivery.

User Story Example 5: 

As a user, I want to be able to pay securely using my preferred method (credit card, wallet, or cash) so that I can easily pay for my order. 

User Story Example 6: 

As a customer, I want to view my past orders so that I can reorder my favorite meals easily.

User Story Example 7:

As a user, I want to receive notifications about my order status and delivery time so that I am updated without having to open the app.

User Story Example 8:

As a customer, I want to be able to rate my order and leave it a review to share my experience and help others make decisions.

User Story Example 9:

As a signed-up user, I want to update my personal information and delivery addresses to guarantee proper delivery of my ordered items.

User Story Example 10:

As a returning customer, I want to apply discount codes and view available deals so I can save money on my orders.

User Story Example 11:

As a shopper, I want to talk to customer service through the app so I can resolve issues with my order more quickly.

Who Writes User Stories?

Anyone can write them. The role of writing the user story isn’t limited to the product owner. In agile project management, every team member can write the user story. 

However, a product owner must ensure a product backlog of user stories exists with all the information needed for the developers.

The next step for developers is to organize the stories by priority and start working on the list accordingly.

When Are User Stories Written?

In general, user stories are written throughout the lifecycle of the project. During the early stage of the agile project management process, the entire scrum team gets together to write the user stories. 

The primary goal of this meeting or workshop is to collaboratively create a product backlog that outlines the features or functions to be included either throughout the project duration or within a three- to six-month release cycle.

Within this dynamic framework, certain user stories evolve into what are termed epics—broad narratives that encapsulate significant functionalities. These epics are subsequently broken down into smaller, more manageable stories that align with the scope of a single iteration.

Elements of a User Story

A user story is built on a framework of core components that give a user story structure and direction. So, let’s explore the essential components of an effective user story.

1. A Unique ID: A Unique ID is used to identify a requirement specifically. When an Application Lifecycle Management (ALM) tool is used, this is a default attribute that is fixed by the team for all requirements.

2. Summary: This is the short or compressed title of the requirement.

3. Description: The Description is the user story in agile described in the standard user story format i.e. “As [a user persona], I want [to perform this action] so that [I can accomplish this goal]”

4. Acceptance Criteria: At this point, it's important to make a list of the Acceptance Criteria. These are the things that need to be met before the user story in agile can be marked as done. Anything in this list is not optional; it must be included in the story.

5. Estimation: Estimation is the process of estimating the effort required to complete a user story in the product backlog. Most of the agile teams estimate the user stories using story points.

6. Status: Status refers to the progress stage of the user story in agile. It may begin with Open, In Analysis, Ready for Dev., In Dev, Idea, Defined, Refined, Planned, In Progress, Completed, Rejected, and Accepted.

The 3Cs Model of User Story (Card, Conversation, & Confirmation)

• 1

  Card - In Agile, a user story is a like short story to describe what a user needs. The card is the written account of the story, with an overall description of the user's intention and value. The card is merely an invitation to a conversation. The card is helpful in sprint planning because it establishes a common starting point for a discussion about user needs. Example card: As a [user] I want to [action] so that [benefit].

• 2

  Conversation - The conversation is when the user story comes to life. It's a discussion involving customers, users, and the development team. Through this dialogue, we delve into the specifics of the user story, clarifying doubts and determining potential solutions. It's not just about the card; it's about refining the details collaboratively.

• 3

  Confirmation - After the development work is finalized, it is necessary to confirm it meets what was agreed upon. Validation is the endeavor of developing criteria for acceptance or establishing tests. These criteria form the benchmark for the product owner or the customer to assess whether or not the user story has been implemented correctly. We have collectively agreed upon these conditions of satisfaction to ascertain that the user story has been satisfied.

Types Of User Stories In Agile

Let's look at the different types of user stories in Agile, and how they can help build products that deliver real user value.

1. Functional User Stories: Functional User Stories are written based on the functional traits of the software and concentrate on the user and the value of the functionality offered to the end user.

2. Technical User Stories: Technical User Stories provide support to functional user stories.

3. Product Infrastructure: Product Infrastructure Stories assist with requested functional stories. This may be inclusive of new or revamped infrastructure.

4. Team Infrastructure: Team Infrastructure stories help the team and their capability to deliver working software. This includes tooling, testing, metrics, design, and planning.

5. Refactoring: Refactoring are technical user stories that identify codes that need refactoring. Refactoring is the process of improving the internal structure of code without altering its external behavior.

6. Bug Fixing: Bug Fixing is a change to a product or system built to handle a programming glitch or bug.

7. Spikes: A Spike is a technical user story where the estimation for the efforts required cannot be determined by the team. These are user stories requiring research on design and architecture helpful in fulfilling the functional needs of the end-user.

Examples of Spikes

Spikes should be timeboxed in story points, and that timebox should contribute to the team's velocity for that sprint.  Spikes are estimated and demonstrated towards the end of the iteration, like other stories. Teams can use Spikes in numerous situations, such as 

Estimating the latest features and capabilities to analyze the implied behavior offers insights to split them into minor, measurable pieces. 

Find out the viability of epics by carrying out feasibility analysis and other activities.

Perform fundamental research to make them aware of a new technology or domain. 

Develop experience in technical and functional approaches, thereby minimizing risk and uncertainty

Examples of Epics

Each Epic represents a large body of work that can later be broken down into smaller user stories.

Product: Food Delivery Application

Epic 1: User Registration and Onboarding

Allow registered users to create an account, verifying their email address before making personalized recommendations based on their preferences.

Epic 2: Restaurant Discovery and Search

Allow users to search for, filter, and hunt for nearby restaurants by type of cuisine, price, ratings, and deals.

Epic 3: Order Placement and Checkout

Ensure a seamless path for users to choose their dishes, customize their order, apply promo codes, and complete a secure payment upon checkout.

Epic 4: Real-Time Order Tracking

Provide real-time updates to customers from the moment they confirm their order to when the delivery is completed by the driver, with live updates on the driver's location.

Epic 5: Ratings, Reviews, and Feedback

Allow customers to share their experience and rate both the restaurant and delivery partner while allowing the customer to examine restaurant reviews before placing their orders.

What Details Are Included In The User Stories?

Imagine you are throwing a surprise birthday event for your best friend and want to arrange a catering company to provide food for the occasion. If you tell the catering company, "I need food for a party," what will they learn about your friend's tastes or food preferences? 

On the flip side, if you tell the caterer an overly detailed food list with ingredient specifications, cooking techniques, and recipes, your food order will have a complicated menu that overwhelms your order.

Hence, you need to give an appropriate level of detail. You need to convey essential information such as the type of cuisine, food preferences (e.g., dietary restrictions), and the overall feeling you want to convey. That gives the caterer the opportunity to design an excellent menu, drawing from their skills and expertise, to represent your vision and be appropriate for the special event you are hosting.

In the same way, when writing user stories, you need to give the proper level of detail. If the Prodigy owner does not provide enough information about the product, the developers will not be able to produce enough thoughts during the sprint planning process to understand what to build.

With too much detail, the developers might feel confused, and they might even deviate from the acceptance criteria. So, how detailed should a user story be? Is there any ideal measurement for this? Here’s what you should know:

• The user story should be detailed enough to define the conditions that must be met.

• Include a set of acceptance criteria that must be met for the entire feature to be considered as done

• The acceptance criteria might include functional and non-functional use cases, what a specific feature is intended to do, end-to-end flow, UI/UX concerns, etc. 

• The product owner should assign priorities to user stories

• Your team can add all these details to the story by breaking it down into multiple smaller user stories. As you write more information into smaller stories, you can consider more details have been added.

Describe the Life Cycle of a User Story?

From the early stage of story creation to completion, the lifecycle of a user story typically follows a set of stages. Let’s keep on reading to find out the brief description of each of the stages.

5. Creation- The user story is initially created during a collaborative session between the product/project team, users, and product owner. During this phase, the user story is a short written description of a desired feature or functionality from an end-user’s POV. At this stage, the team doesn’t discuss anything in detail. The main goal of this initial creation stage is to remind the team about the scope of future discussion on the user story.

6. Prioritization- In the next stage, the user story goes through a phase of prioritization. Usually, the role of a product owner is to prioritize user stories based on business value and project requirements. Prioritization helps the team focus on the most critical features and functionalities early in the development process.

7. Estimation- During the estimation stage, the developers estimate the efforts needed to implement each user story. The team puts the user stories into a time-boxed event called Sprint. The team estimates the effort and duration necessary for each user story in order to allow adequate planning and resource allocation for future sprints.

8. Discussion- In the discussion phase, the developers have the opportunity to discuss the scope and acceptance criteria of each user story. If there are misunderstandings, misinterpretations, or general questions concerning the user stories, these can be clarified.  The development team will collectively agree upon the acceptance criteria that are to be met for each user story. For each story, the team may also create smaller tasks or sub-tasks to break down the user story further; this breakdown will aid not only in the assignment of work, but also in the ability to gauge progress over the sprint and identify issues ahead of time.

9. Development- After the development team gets a working understanding of the acceptance criteria, requirements, and uncertainties of each user and task, they will work on the specified features. Team collaboration at this point, specifically between developers, testers, and the other stakeholders, is necessary.

10. Testing- The implemented user story will be tested to ensure that it meets the acceptance criteria agreed upon before work began, while ensuring that no new issues are introduced. The testing will typically include: functional testing, integration testing, and regression testing.