Software Quality.com

user story

By Yvette Francino

What is a user story?

A user story is a tool in Agile software development used to capture a description of a software feature from a user's perspective. The user story describes the type of user, what they want and why. A user story helps to create a simplified description of a requirement.

The purpose of a user story is to write down how a project will deliver value back to the end user. It is then the development team's job to take care of how to develop the code that will satisfy the requirements of the user story. In best-case scenarios, developers collaborate closely with the business owners and stakeholders to clarify the details as they develop code.

User stories do not replace use cases or technical requirements documentation. Instead, product developers can write user stories to help prioritize how functionality is going to be added to a project over the project timeframe. A user story can be considered a starting point to a conversation that establishes the real product requirement.

The user story can fit into Agile frameworks like Scrum and Kanban.

Characteristics of a user story

A user story template often follows the same format. The three components of a user story are:

1. Who. This is typically a job role, customer or type of user, also known as the user persona.
2. What. This is the goal that the user wants the product to accomplish or implement.
3. Why. This is the reason the user needs the feature or functionality.

The result is a sentiment like, “As a <who>, I want <what> so that <why>.” Developers can add further detail to a user story by breaking it into smaller user stories and grouping them into themes.

An Agile user story is meant to be short, usually fitting on a sticky note or note card. The business should write user stories in the language of the customer so that it is clear to both the business and the development team what the customer wants and why they want it.

In some cases, developers assign user stories a unique identifier and an effort/priority level. The unique identifier is typically a number and allows developers to keep track of how many user stories there are and when they are completed. The effort or priority level is more customized to the team but is typically a range that signifies how long the feature will take, how many developers will be needed or how many requirements the feature has.

Lastly, user stories should be associated with pre-defined acceptance criteria. Acceptance criteria identify the boundaries of a user story and what needs to be done for the story to be considered complete. This could also include any tests that need to be done to verify a user story.

Examples of user stories

Following the above format, a few examples of a user story are:

• As a user, I want to upload photos so that I can share photos with others.
• As an administrator, I want to approve photos before they are posted so that I can make sure they are appropriate.
• As a social media manager, I want to tag the photos under specific categories so that I can filter and search the photos for future use.

Benefits of user stories

User stories provide development teams with important context before a project even begins. They place emphasis on the user and focus on solving real situations a customer might face. This can help development teams think more critically and creatively. Additional benefits of using user stories include:

• Increased visibility and collaboration across the development team.
• Better use of end user or customer feedback.
• Can save time when prioritizing the development of requirements and functionality.
• Helps avoid restrictions that occur when specification details are defined too early on.
• Higher clarity around business value and delivering products that end users actually need.

Editor's note: This article was written by Yvette Francino in 2020. TechTarget editors revised it in 2022 to improve the reader experience.