What is a user story?
A user story is a short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. User stories typically follow a simple template:
As a < type of user >, I want < some goal > so that < some reason >.
Historically user stories were deliberately kept informal, written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. Their impermanence made it easy to tear them up, throw them away, and replace them with new stories as more was learned about the product being developed.
Today, user stories might just as easily be stored in a Jira issue or Trello board. Don't let the fact that a user story exists in a tool make you any less willing to discard stories when they are no longer needed!
User stories are designed to strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.
What is a good user story?
Agile user stories are composed of three aspects that Ron Jeffries named in 2001 with the wonderful alliteration of card, conversation, and confirmation:
- Card: Written description of the story, used for planning and as a reminder
- Conversation: Conversations about the story that serve to flesh out the details of the story
- Confirmation: Tests that convey and document details that can be used to determine when a story is complete.
User stories have many advantages, but the most important might be that every user story is a placeholder for a future conversation.
How to write a user story
Writing good user stories in Scrum requires an understanding of the basic user story template, a focus on the user or customer, and a clear picture of the desired functionality.
The user story template
When writing a user story, remember that user stories follow a standard template:
As a < WHO >, I want < WHAT > so that < WHY >.
Examples of user stories
One of the best ways to learn how to write a user story in agile is to see examples. Below is an example user story or two. These are a few real examples of user stories that describe the desired functionality in an early version of the Scrum Alliance website.
- As a site member, I can fill out an application to become a Certified Scrum Trainer so that I can teach Certified Scrum Master (CSM) and Certified Scrum Product Owner (CSPO) courses and certify others.
- As a trainer, I want my profile to list my upcoming classes and include a link to a detailed page about each so that prospective attendees can find my courses.
- As a site visitor, I can access old news that is no longer on the home page, so I can access things I remember from the past or that others mention to me.
- As a site visitor, I can see a list of all upcoming “Certification Courses” and can page through them if there are a lot, so I can choose the best course for me.
Note that you don't see any user story, "As a product owner, I want a list of certification courses so that..." The product owner is an essential stakeholder, but is not the end user/customer. When creating user stories, it's best to be as specific as possible about the type of user.
Ask GoatBot your user story questions
Who writes user stories?
Who writes user stories? Anyone can write user stories.
Does the product owner write user stories?
It's the product owner's responsibility to make sure a product backlog of agile user stories exists, but that doesn’t mean that the product owner is the one who writes them. Over the course of a good agile project, you should expect to have user stories written by each team member.
Also, note that who writes a user story is far less important than who is involved in the discussions of it.
When are user stories written?
User stories are written throughout the agile project. Usually a story-writing workshop is held near the start of the agile project. Everyone on the team participates with the goal of creating a product backlog that fully describes the functionality to be added over the course of the project or a three- to six-month release cycle within it.
Some of these agile user stories will undoubtedly be epics. Epics will later be decomposed into smaller stories that fit more readily into a single iteration. Additionally, new stories can be written and added to the product backlog at any time and by anyone.
Show other user story examples
As a more generic example of writing user stories in Scrum, these are some typical user stories for a job posting and search site:
- A user can post her resume to the web site.
- A user can search for jobs.
- A company can post new job openings.
- A user can limit who can see her résumé.
Examples of epics
One of the benefits of agile user stories is that they can be written at varying levels of detail. We can write a user story to cover large amounts of functionality or only a small distinct feature.
Large user stories are less detailed, and are generally known as epics.
Here is an epic agile user story example from a desktop backup product:
- As a user, I can backup my entire hard drive.
Because an epic is generally too large for an agile team to complete in one iteration, it is split into multiple smaller user stories before it is worked on. The epic above could be split into dozens (or possibly hundreds), including these two example user stories:
- As a power user, I can specify files or folders to backup based on file size, date created and date modified.
- As a user, I can indicate folders not to backup so that my backup drive isn't filled up with things I don't need saved.
200 User Stories Examples
How is detail added to user stories?
Detail can be added to user stories in two ways:
- By splitting a user story into multiple, smaller user stories.
- By adding conditions of satisfaction (acceptance criteria).
When a relatively large story is split into multiple, smaller agile user stories, it is natural to assume that detail has been added. After all, more has been written.
The conditions of satisfaction is simply a high-level acceptance test that will be true after the agile user story is complete. Consider the following as another agile user story example:
As a vice president of marketing, I want to select a holiday season to be used when reviewing the performance of past advertising campaigns so that I can identify profitable ones.
Detail could be added to that user story example by adding the following conditions of satisfaction:
- Make sure it works with major retail holidays: Christmas, Easter, President’s Day, Mother’s Day, Father’s Day, Labor Day, New Year’s Day.
- Support holidays that span two calendar years (none span three).
- Holiday seasons can be set from one holiday to the next (such as Thanksgiving to Christmas).
- Holiday seasons can be set to be a number of days prior to the holiday.
Do user stories replace requirements documents?
Agile projects, especially Scrum ones, use a product backlog, which is a prioritized list of the functionality to be developed in a product or service. Although product backlog items can be whatever the team desires, user stories have emerged as the best and most popular form of product backlog items.
While a product backlog can be thought of as a replacement for the requirements document of a traditional project, it is important to remember that the written part of an agile user story (“As a user, I want …”) is incomplete until the discussions about that story occur.
It’s often best to think of the written part as a pointer to the real requirement. User stories could point to a diagram depicting a workflow, a spreadsheet showing how to perform a calculation, or any other artifact the product owner or team desires.
Recommended Resources
