User Stories: A Beginner's Guide to Writing Them Well
A user story is a brief, informal description of a feature from the perspective of the user who will use it. The standard format is: 'As a [type of user], I want [some goal] so that [some reason].' User stories are the primary way that work is captured in a Product Backlog in Scrum. They are deliberately brief -- the three-part format is a reminder that work exists to serve a user need, not as an end in itself.
What User Stories Are (and Are Not)
A user story is not a complete requirements specification. It is an invitation to a conversation. The story captures the who, what, and why -- enough to have a conversation about the how. The acceptance criteria that accompany the story capture the specific conditions that must be met for the story to be considered done. A user story without acceptance criteria is incomplete.
A user story is not a task. A task is a unit of work done by the team. A user story is a unit of value delivered to the user. A feature may require multiple tasks to implement, but it should be expressed as a single user story (or a small number of stories) from the user's perspective.
The INVEST Criteria for Good User Stories
Independent. Stories should be independent of each other, so they can be developed and delivered in any order. Stories with strong dependencies are harder to prioritise and schedule.
Negotiable. Stories are not fixed contracts. The details of how the story is implemented are negotiable between the Product Owner and the Development Team.
Valuable. Every story should deliver value to the user or customer. If the value is not clear, the story should be revised or discarded.
Estimable. The team should be able to estimate the story. A story that cannot be estimated is either too large or not well enough understood.
Small. Stories should be small enough to be completed within a Sprint. Stories that are too large are called epics and should be broken down.
Testable. The story should have acceptance criteria that define what done means. If the story cannot be tested, it cannot be verified as done.
Common User Story Mistakes
Writing from the developer's perspective rather than the user's perspective. 'As a developer, I want to refactor the authentication module so that...' is a task, not a user story. Refactoring work should be tracked as a technical story, clearly labelled, and prioritised by the Product Owner against user-facing stories.
Omitting the 'so that' clause. The reason a user wants a feature is critical context for the Development Team. 'As a manager, I want to export the report to Excel so that I can share it with stakeholders who do not have system access' tells the team why the feature matters and may reveal better ways to achieve the goal.
Writing stories that are too large. An epic that will take an entire Sprint or more is not a story -- it is a feature. Break it into smaller stories, each of which delivers value on its own.
Confusing user stories with acceptance criteria. User stories describe intent; acceptance criteria describe verification conditions. Both are needed.
XNM provides Scrum coaching and agile delivery advisory to public-sector organisations. Reach out to XNM's program & project delivery advisory team to discuss user story practices and Scrum implementation for your organisation.