User stories
Describe what to build as small, testable needs written from the user's side, so the team builds the right thing and knows when it is done.
- Time
- 45 min
- People
- 3–6
- Kind of work
- Plan
In short
A user story is a short statement of one user need, written as "As a [user], I need [something], so that [reason]", with acceptance criteria that say when it is done. To write them, start from research, group related stories into epics, split large ones, and agree criteria with the people who will build and test them.
What it is
A user story describes a piece of work from the point of view of the person who will use it, rather than as a technical task. It has three parts: who the user is, what they need, and why they need it. The "so that" part matters most, because it tells the team what problem the work solves and lets them suggest a better way to solve it. Each story carries acceptance criteria: a short list of conditions that must be true for the story to count as done.
User stories come from agile software practice and were first used in Extreme Programming in the late 1990s. They are now standard in digital service teams, including in government. The GOV.UK Service Manual uses the wording "I need" rather than "I want", to keep the focus on real needs. Large stories that cover a whole goal are called epics and are broken down into smaller stories that can be built and tested in a short time. In this worksheet you record the user, the need, the reason, the acceptance criteria, the epic it belongs to and the evidence behind it.
When to use it
Use it when
- You have finished research and design work and need to turn it into a list of work a delivery team can build.
- A requirements document is long and technical, and nobody can say which parts matter most to users.
- You are planning the first release of a new service and need to agree what is in and what can wait.
- Business, policy and technical teams describe the same service in different words and keep misunderstanding each other.
- You need clear conditions for testing, so that everyone agrees when a feature is finished.
Skip it when
- You do not yet know who your users are or what they need. Do research first, or the stories will describe guesses.
- The work is purely technical with no user-facing change, such as upgrading a database. A plain task description is clearer.
- You are still exploring very different ideas. Stories fix detail too early; use a storyboard or prototype first.
You need
- Time
- About 45 minutes to draft and review stories for one epic; more for a whole service.
- People
- 3 to 6 people: a product or service owner, someone from the research, and at least one person who will build and one who will test.
- Materials
- Research findings or a journey map, index cards or a shared board, and a simple template with the six worksheet fields.
How to run it
Step 1: Start from the user's goal
Write the overall goal of one group of users at the top of the board, for example "a member applies for a retirement pension". This becomes the epic. Pin the relevant research, such as quotes, a journey map or a point of view statement, beside it so the stories stay tied to evidence.
Step 2: Name the users precisely
List the types of user involved in the goal, in plain words: "a member retiring this year", "a member's employer", "a pensions officer". Avoid "as a user" and "as the system"; they hide whose need it is. Staff are users too and get their own stories.
Step 3: Draft the stories
Have each person write stories on separate cards in the form "As a…, I need…, so that…". Write the need in the user's terms, not as a screen or a button: "I need to know which documents to send" rather than "I need a document upload page". Aim for one need per card.
Step 4: Check the "so that"
Read each card aloud and ask whether the reason is real and specific. "So that I can apply" adds nothing. "So that my first payment is not delayed" tells the team what success looks like. If nobody can say why the user needs it, take the card out or mark it as an assumption to check.
Step 5: Split large stories
If a story would take a team more than a few days to build and test, split it. Good ways to split are by user type, by step in the journey, by simple and complex cases, or by the main path first and exceptions later. Keep the split stories under the same epic.
Step 6: Write acceptance criteria
For each story, agree three to six conditions that must be true when it is done, written so a tester can check them. A useful pattern is "Given [situation], when [action], then [result]". Include the unhappy paths, such as a missing document or a wrong number, not only the main one.
Step 7: Order and record
Arrange the stories under the epic in the order users meet them, then mark which ones are needed for the first release. Record each story with its evidence and criteria in the team's backlog, and agree who will review the stories with the research team before building starts.
Worked example
A public pension fund received about 3,400 retirement applications a month, nearly all on paper. Applications took an average of 47 days to process, and 38% were sent back to the member at least once for missing or wrong information. The fund planned an online service and had a 400-page requirements document that the delivery team found hard to use.
Five people met for 45 minutes: the service owner, a user researcher, a pensions officer, a developer and a tester. They took the epic "a member applies for a retirement pension" and placed interview quotes and the journey map beside it.
They listed four users: a member retiring this year, a member's employer, a pensions officer and a member's appointed relative. The first draft produced 26 story cards.
Checking the "so that" removed four cards that only restated the step. It also changed "As a member, I need to upload my service certificate" into "As a member retiring this year, I need to know my employer has already confirmed my service dates, so that I do not have to collect a certificate myself".
The story about calculating the pension was too large. The team split it into three: members with one employer, members with several employers, and members with gaps in their contributions, and marked only the first for release one.
Acceptance criteria for the service-dates story included "Given the employer has confirmed the dates, when the member signs in, then the dates are shown and can be accepted" and "Given the dates are missing, when the member signs in, then they see who to contact and the case is flagged for an officer".
The final backlog for the epic held 18 stories, 11 of them marked for the first release. The team booked a review with the researcher before the first sprint.
IllustrativeTips and mistakes
Tips
- Write the need as something the user wants to achieve, not as a feature. It leaves room for the team to find a simpler solution.
- Keep stories small enough to build and test within a sprint or a week. Large stories hide risk.
- Write stories for staff users too. Officers who process cases have needs that shape the whole service.
- Link every story to the evidence behind it, so anyone can check where a need came from.
Common mistakes
- Writing "As a user" for everything, which hides the different needs of different people.
- Turning a technical task into a story by adding "As the system", which defeats the purpose of the format.
- Leaving out acceptance criteria, so the team and the testers each decide what done means.
- Writing the full backlog alone at a desk and handing it over, instead of drafting and checking it with the team.
What you walk away with
You leave with an epic broken into small user stories, each naming the user, the need and the reason, with acceptance criteria, a link to evidence and a mark for the first release. The stories go straight into the delivery team's backlog. A roadmap helps sequence epics over time, and a storyboard can show how the stories add up to one experience.
Questions people ask
Why does GOV.UK use "I need" instead of "I want" in user stories?
"I need" keeps the focus on what users must be able to do to get the outcome, rather than on preferences. It pushes teams to ask for evidence that the need is real. Many teams outside government use "I want"; the structure of the story is the same.
What is the difference between an epic and a user story?
An epic is a large user goal, such as applying for a pension, that is too big to build in one go. A user story is one small part of that goal that a team can build and test in a few days. An epic usually contains several stories, sometimes dozens.
How many acceptance criteria should a user story have?
Usually three to six. Fewer may mean the story is vague or that unhappy paths have been missed. Many more often means the story is too large and should be split.
Tool card
The worksheet your team fills in, one box per field.
- User
- Need
- So that
- Acceptance criteria
- Epic
- Evidence