User stories describe a user and the reason why they need to use the service you’re building.
You must use user stories when building your service - they’re essential to building and running a service that meets user needs.
You should make sure every member of your team writes user stories and uses them to:
Your user stories should include enough information for your product manager to decide how important the story is. They should always include:
They’re usually written in the format:
As a… [who is the user?]
I need/want/expect to… [what does the user want to do?]
So that… [why does the user want to do this?]
Example:
The Register to vote service’s user story is ‘as a UK resident, I want to get my details on the electoral register so that I can vote’.
You don’t have to use this format but you should always briefly explain the actor, the narrative and the goal.
The most important part of a user story is the goal. This helps you:
If you’re struggling to write the goal then you should reconsider why you think you need that feature.
You can also include a few acceptance criteria for each story. Acceptance criteria are a list of outcomes that you use as a checklist to confirm that your service has done its job and is meeting that user need.
They’re often written as a list that begins with ‘it’s done when…’.
Example:
The acceptance criteria for the Register to vote service are the following:
Use the acceptance criteria to link to any evidence (for example spreadsheets or diagrams) that support the story.
Large user stories (ones that would take more than a few weeks to develop and test) are typically called epics. If possible, split a large story or epic into smaller stories that can be completed within an iteration.
Record each user story on a card and give it a title. The cards can be:
When you have a lot of stories, you might want to keep them in a digital format (like Trello or a spreadsheet) and then turn them into physical cards as part of planning.
You should put all your stories in your backlog where your product manager will organise them in order of priority. They will then sit in the backlog until your team decides they are ready to work on them.
Your product manager and relevant team members can have a more in-depth discussion about the story when they’re ready to start work on it. You should record more detail from these discussions in the user story.
You may also find these guides useful: