Writing User Stories
Basic
difficulty
Stage 2
Agile IQ® Level
Backlog Management
Practices
XP
Framework
Introduction
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:
User stories, first coined by Alistair Cockburn in 1998, were originally informal, written on cards or sticky notes and arranged on walls or tables for planning and discussion. They were easily discarded and replaced as more information about the product emerged.
Today, User Stories can be stored in tools like Jira or Trello. However, the fact that they are in a tool should not prevent you from getting rid of Stories that are no longer relevant.
The main purpose of User Stories is to shift the focus from writing about features to discussing them. The discussions themselves are more important than the actual text of the stories.
Format
The User Story in its most brief format addresses questions like:
- Who needs this feature?
- What is the context of its use?
- Why is it valuable?
This is considered the minimum amount of information for a Product Owner to commence discussions with team members about the problem that the team needs to solve and to find a workable, minimally viable solution.
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.
User Story template
When writing a User Story, remember that it follows a standard format:
As a [type of user], I want [some feature], so that [some reason].
How NOT to write a user story
User Stories focus on the person using a feature, not the person requesting it. More specifically, this is an end user, not:
- The Product Owner
- A developer or tester
- An IT system or API
- Another team
- The organisation
- An internal stakeholder
If there is no real ‘end user’ or customer, use a different format to write the Story, e.g. the Three Cs – Card, Conversation, Confirmation.
Focus on conversations to solve problems not deliver 'requirements'
Great teams use User Stories to create the shortest means possible to create sufficient knowledge about the problem they need to solve and its context.
Examples of User Stories
Do Stories replace traditional requirements documents?
Agile teams, especially those that use Scrum, use a Product Backlog: a prioritised list of the functionality to be developed in a product or service. Although Product Backlog items can be in whatever format works for that team, User Stories have emerged as the defacto format of Product Backlog items.
While a Product Backlog can be thought of as a replacement for a requirements document in a traditional project, it is important to note that the User Story component (“As a user, I want …”) is incomplete until the discussions about that story occur. The collection of other material, acceptance criteria, designs, workflow diagrams, business rules, and other elements, ultimately form a more complete form of the requirement.
Try documenting 'as built' instead of attempting to define all the requirements up-front
Upfront documentation rarely represents the state of the final design and build. Great teams who operate in high compliance environments with audit needs around documentation will often, once a Story has been complete, then spend time documenting the 'as built' requirement as part of their Definition of Done. This saves time re-writing documentation.
What else does a good User Story contain?
Acceptance Criteria
An estimation of size, so the team understands whether it will fit into a Sprint or not.
Some kind of high-level design, UI wireframes, architecture, data, what ever is needed to guide the team and align the solution to the product’s standards and any organisational compliance needs.
Other Types of Stories
The Scaled Agile Framework (SAFe) has made a number of different types of Stories popular:
- Epics: Used for portfolio-level Stories.
- Features: Used for Agile Release Train-level Stories.
Epics
SAFe uses a Portfolio Backlog to manage Epics for several Agile Release Trains.
- Epics represent a large initiative that span multiple Planning Increments. These are the equivalent of multi-million dollar investments by executives.
- Epics break down into multuiple Features. Each Feature must be sliced and sized so that it can be delivered within a single Planning Increment (no more than 6 Sprints).
- Epics are written and managed by Epic Owners on behalf of executives. Epic Owners are often the Product Owners who will eventually deliver the Epic once it is broken down into Features and Stories.
- Architects and other people in Product Management in an Agile Release Train will contribute to the Epic until it is ready to be discussed with Product Management prior to a Planning Increment event.
Features
SAFe uses an ART Backlog to manage Features for the Agile Release Train.
- Features are managed in an ART Backlog by the Agile Release Train’s Product Manager.
- Features are often written by the Product Owners who will eventually deliver the Feature once it is brokwn into Stories.
- Architects and other people in Product Management will contribute to the Feature until it is ready to be discussed with teams prior to a Planning Increment event.
- Features must be defined and sliced in a way that they will fit into a Planning Increment (no more than 6 Sprints).
- Features are broken down into multiple Stories for teams, typically at the Planning Increment event for the whole Agile Release Train. Stories are then managed in a Team Backlog.
References
1. 2001: The Card, Conversation, Confirmation model was proposed by Ron Jeffries to distinguish “social” User Stories from “documentary” requirements practices such as Use Cases.
2. Cohn, M. (2023) User Stories. Online at: mountaingoatsoftware.com/agile/user-stories
All fields are required.
