MethodsUser stories
What
A short, plain-language description of a product feature or requirement written from the perspective of the user.
Why
To frame the problem we’re solving around the needs of the people who will use the product, rather than the limitations of the technology or the program or agency overseeing it. User stories help us break down a large development effort into smaller, more manageable slices so that we can track progress, plan sprints, and prioritize work around user impact. They also encourage us to talk about features in plain language and make the discussions (and solutions) more accessible.
How to do it
- Start by defining the project’s epics—typically the larger, high-level “themes” or bodies of work that make up the initiative.
- Break down each epic into pieces of work that can be independently estimated, developed, and tested. These will become your user stories.
- For each piece of work you identified, write a story from the user’s perspective of who they are, what they want to do, and why. User stories typically follow this template:
As a < type of user >, I want < some goal > so that < some outcome >.
Note: Only make the type of user as specific as you need to. If the piece of work is needed by all your users, it’s ok to say “as a system user.” That way when it is specific (“as a first-time applicant”) it’s clear that this is a group with particular needs.
- Consider possible harms to the user, the system, or external to the system by adding a second part of the sentence:
…while avoiding < potential negative impacts > to < the user, the system, or external to the system >.
- User stories can be the basis for tickets—a tool to manage and track work for the solution you’re building. These tickets should include the story, a brief description, and a list of acceptance criteria.
Additional resources
Considerations for use in government
No PRA implications. No information is collected from members of the public.
