What are user stories?

User stories are short and simple descriptions of a feature or functionality that a user wants to achieve. They are written from the user’s perspective and focus on the value or benefit that the user will get from the feature. User stories are one of the core elements of Agile software development, as they help the team understand the user’s needs and expectations and deliver solutions that meet them.

How to write user stories in Agile?

Writing user stories in Agile can be approached in several ways, each with its own focus and structure. Here are some common formats:

1. Standard User Story Format:

This is the most widely used format and follows the template: As a [type of user], I want [an action] so that [a benefit/a value]. This format helps to capture the user’s role, goal, and motivation in a concise and clear way.

Example: “As a customer, I want to be able to track my order status so that I can know when it will arrive.”

This user story expresses who the user is (a customer), what they want to do (track their order status), and why they want to do it (to know when it will arrive).

2. INVEST Criteria

This principle ensures that user stories are:

Independent: Can be developed separately without depending on other stories.

Negotiable: Can be changed and refined based on feedback and collaboration.

Valuable: Provides value to the user and the business.

Estimable: Can be estimated in terms of effort, time, and resources.

Small: Small enough to be completed in a sprint (a short iteration of development).

Testable: Can be tested to confirm it works as expected and meets the acceptance criteria.

Example: User story –As a: Registered user I want: To log into the application using my email and password So that: I can access my personalized dashboard and settings

1. Independent– The story can be developed and delivered independently of other stories. It doesn’t rely on other features being completed first.
2. Negotiable– The details of the story can be discussed and refined with the team. For example, the exact requirements for password complexity can be adjusted based on feedback.
3. Valuable-The story provides clear value to the user by allowing them to securely access their personalized information.
4. Estimable– The team can estimate the effort required to implement the story. They can break down the tasks needed to create the login functionality.
5. Small– The story is small enough to be completed within a single sprint. If it’s too large, it can be broken down into smaller tasks, such as “Create login form” and “Implement authentication logic.”
6. Testable– The story has clear acceptance criteria that can be tested.

3. Three C’s (Card, Conversation, Confirmation)

Card: Write the user story on a card. This helps to keep it simple and visible.

Conversation: Discuss the story with the team and the stakeholders to gather details, clarify requirements, and resolve issues.

Confirmation: Define acceptance criteria to confirm when the story is done. This helps to ensure the story meets the user’s expectations and can be tested effectively.

Example: “As a traveler, I want to book a flight online so that I can save time and money.”

Card: Write this user story on a card and post it on a board.

Conversation: Talk to the traveler, the developers, the testers, and the product owner to understand the user’s needs, the technical feasibility, the design options, and the business value.

Confirmation: Specify the conditions that need to be met for the story to be done, such as: The traveler can search for flights by date, destination, and price. The traveler can select a flight and enter their personal and payment information. The traveler can confirm their booking and receive a confirmation email.

4. User Personas

Create detailed personas representing different user types. Write stories from the perspective of these personas to ensure diverse user needs are met. User personas are fictional characters that embody the characteristics, behaviors, and goals of real users. They help to empathize with the user and design solutions that suit their needs.

Example: “As Alice, a busy working mom, I want to order groceries online so that I can save time and avoid going to the store.”

This user story is based on a user persona named Alice, who has a specific background, lifestyle, and pain point. Writing stories from her perspective helps to address her needs and expectations.

5. Job Stories

Focus on the job the user wants to accomplish rather than the user themselves. The format is: When [situation], I want to [motivation] so I can [expected outcome]. This format helps to capture the user’s context, motivation, and desired outcome in a specific situation. It also helps to avoid making assumptions about the user’s identity or preferences.

Example: “When I am on the go, I want to check my email quickly so I can stay updated with work.”

This job story expresses what the user wants to do (check their email), why they want to do it (to stay updated with work), and when they want to do it (when they are on the go). It does not assume who the user is or how they want to check their email.

6. Acceptance Criteria

The Given/When/Then format is a structured way to write acceptance criteria for user stories in Agile development. It helps ensure that all scenarios are covered and that the requirements are clear and testable. Here’s a detailed breakdown:

Structure of Given/When/Then

1. Given:
   • This part sets up the initial context or preconditions for the scenario. It describes the state of the system before any action is taken.
   • Example: “Given that I am logged into the application as an admin…”
2. When:
   • This section specifies the action or event that triggers the scenario. It describes what the user does or what event occurs.
   • Example: “When I navigate to the user management page and click the ‘Add User’ button…”
3. Then:
   • This part describes the expected outcome or result of the action taken in the “When” section. It outlines what should happen if the preconditions are met and the action is performed.
   • Example: “Then a new user form should be displayed, allowing me to enter user details.”

Example Scenario

Let’s put it all together with a complete example:

User Story:

As a product manager,
I want to score potential ideas,
So that I can decide what to include on my product roadmap.

Acceptance Criteria:

Scenario: The product manager adds potential ideas and ranks the best ideas based on benefit versus cost.

Given that I have added two or more ideas and scored them using the Benefit vs Cost scoring model, When I click the Rank button, then ideas are sorted with the top-scoring ideas at the top.

In conclusion, user stories are a powerful way to capture the user’s voice and deliver value in agile projects. By writing user stories that are concise, relevant, and testable, developers can create products and services that meet the user’s expectations and solve their problems.