On this page
A user story is a compact description of a need in context. It helps a team discuss why a piece of work matters and what successful behavior would make possible. The familiar sentence template is optional; a perfectly formatted sentence can still describe the wrong problem.
Start with a person trying to accomplish something under particular conditions. Then state the useful outcome. Keep the story small enough to discuss, but do not remove the end of the journey merely to make the ticket look easier.
Replace the generic user with a relevant situation
“As a user, I want a dashboard” gives the team little basis for choosing content or behavior. A more useful description might concern a volunteer coordinator who needs to identify unfilled shifts before sending the weekly schedule.
The role matters because it explains authority, information, and context. Do not add demographic details that have no bearing on the task. A story should clarify the need without turning an imagined persona into evidence about actual people.
Record the source of the need. It might come from research, support cases, observation, or an operational requirement. If it is an assumption, label it and identify how the team will check it.
Explain the outcome behind the request
A requested feature often contains an unstated purpose. Ask what the person will do differently once the feature exists. In the coordinator example, the goal is to fill uncovered shifts, not merely view a colorful chart.
This distinction leaves room for a simpler solution. A filtered list with clear ownership might serve the need better than a complex dashboard. The story should preserve the outcome while design work explores the interface.
Avoid attaching a vague business benefit to every sentence. “So that engagement improves” may be too distant from the action to guide a reviewer. Describe the immediate useful result first and connect broader measures separately.
Include enough context for a real discussion
State the starting condition and the important boundary. The coordinator may need to see only shifts they are authorized to manage, or may be working from a phone while traveling between locations. Those details can change the design.
Do not bury an essential permission rule in a later technical comment. If seeing another team's private information would violate the intended behavior, make that boundary visible in the story's supporting notes and acceptance criteria.
Keep unrelated requirements out of the same story. A change to shift visibility does not automatically include payroll reporting, recruitment, and attendance tracking. Link related work without pretending it is one small need.
Add examples that make ambiguity visible
Use a small fictional dataset to discuss the behavior. Suppose three shifts are fully staffed and two have open places. What should the coordinator see? What changes when another volunteer accepts one of the open places?
Include a case with no matching results. Does the page clearly explain that there are no uncovered shifts, or does it look broken? An empty state is part of the experience, not merely a styling detail.
Examples are especially useful when people use the same word differently. “Available” might mean that a shift has capacity, that the volunteer is free, or that the coordinator has permission to edit it. Resolve the meaning before implementation begins.
Split by useful behavior rather than by screen layer
A story that covers database fields alone may be a necessary engineering task, but it does not yet deliver the user's outcome. Keep technical tasks linked to the larger behavior so the team can see what remains incomplete.
One possible first slice is a read-only view of uncovered shifts for a single location. A later slice may add an invitation action. Each slice should have a clear purpose and finish, with the temporary limitations stated honestly.
Do not call a slice complete if the user cannot reach it through the intended route or if it depends on an unbuilt manual step nobody owns. A demonstration screen is useful evidence for a prototype, but it is not automatically a finished production workflow.
Write acceptance criteria around observable results
For the fictional shift view, criteria might establish that authorized coordinators see the relevant uncovered shifts, fully staffed shifts are excluded, and the empty state explains when no action is needed. The exact criteria depend on the service's rules.
Add the important failure behavior. If the data cannot load, the interface should not present an empty list as proof that every shift is covered. The user needs a clear distinction between a valid empty result and unavailable information.
Avoid criteria that simply repeat implementation choices, such as “a component named ShiftPanel exists.” That may help a code review, but it does not establish that the coordinator can complete the task.
Keep discussion and decision connected
A short story is an invitation to discussion, not a replacement for it. Record material decisions where the team will find them, especially when the decision changes scope, permissions, or the meaning of completion.
If research reveals that the original need was misunderstood, revise or retire the story. Finishing a ticket because it was already estimated is not a useful reason to build behavior that no longer serves the intended outcome.
At review time, return to the actual situation and show the completed journey. Explain what is supported, what remains outside scope, and what evidence was collected. The story has done its job when it helps the team distinguish a working outcome from a collection of finished tasks.
Sources and further reading
Primary and contextual sources used to verify definitions or give readers a relevant next resource.
- GOV.UK Service Manual: Writing user stories A useful story identifies the actor, need, and goal, with acceptance criteria that describe the intended outcomes.
- GOV.UK Service Manual: Learning about users and their needs Research should establish what people are trying to accomplish and the barriers in their current experience.