A user story is one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function. It is commonly used in Agile-based software development projects to capture requirements.
User story is a format for expressing business value of backlog items, especially features. They are written in a form that is understandable to both business and technical people.
A large user story, perhaps several months in size, that can span an entire release or multiple releases is referred to as an epic.
Template for a Good User Story
Image credit: Kenneth S. Rubin, CC BY-SA 4.0, via Wikimedia Common
A good template for a user story is to express it in terms of who, what, and why as shown below:
“As a [persona], I want [functionality], so that [benefit].”
Some examples of a good user story are:
- As a user of the PMP exam simulator, I want to be able bookmark exam questions, so that I can review them later.
- As a moderator of the forum, I want to be able to ban users, so that I can keep the discussions meaningful.
- As a customer of the ecommerce site, I want to be able to read product reviews, so that I can make an informed purchase decision.
Three C’s of a User Story
The three C’s of a good user story are:
Card refers to the description of a user story. A good user story is usually brief such that it can fit on a 3x5 index card. The template and examples provided above illustrate this point.
Though a user story itself is brief, the details must emerge through conversation between the business representative (usually the product owner), and the project team members. This also reflects the agile value of “Individuals and Interactions over Processes and Tools”.
Confirmation refers to the acceptance criteria of the user story. The project team members must have a clear understanding of the acceptance criteria before they start working on a user story.
Characteristics of a Good User Story
The acronym INVEST helps to remember a widely accepted set of criteria, or checklist, to assess the quality of a user story. It stands for:
For example, a user story that says “the application should be fast” is not considered good because it’s not testable.
Read the article INVEST in Good Stories, and SMART Tasks for a more in-depth understanding.
- Acceptance tests are used to confirm individual user stories.
- Done Criteria are a set of rules that are applicable to all user stories in a given iteration.