Select Page

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. We start writing user stories in the design phase, but refine them again and again, up until right before each sprint planning meeting – where we review them in order of priority.

You should make sure every member of your team writes user stories and uses them to:

  • track everything they need to do
  • think about their work from a user’s perspective
  • discuss their work with colleagues
  • prioritise their work

How to write a user story

What to include

Your user stories should include enough information for your product owner to decide how important the story is. They should always include:

  • the person using the service (the actor)
  • what the user needs the service for (the narrative)
  • why the user needs it (the goal)

The right format for user stories

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:

A blue badge user story is ‘As an elderly person who can’t walk very far, I want a blue badge so that I don’t have to struggle when going to the shops’.

You don’t have to use this format but you should always briefly explain the actor, the narrative and the goal.

Focus on the goal

The most important part of a user story is the goal. This helps you:

  • make sure you’re solving the right problem
  • decide when the story is done and a user need is met

If you’re struggling to write the goal then you should reconsider why you think you need that feature.

Acceptance criteria

It is also really important to 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.  These really help in the alpha and beta phases when the developer is working on the story – as it is very clear to them what ‘done’ looks like for each one.

They’re often written as a list that begins with ‘it’s done when…’.

Example:

Some of the acceptance criteria for the blue badge service are the following:

  • ‘it’s done when the user knows how to apply online’
  • ‘it’s done when the user knows how to apply over the telephone’
  • ‘it’s done when the user knows what the eligibility criteria is to get a badge’
  • ‘it’s done when the user knows what they need to provide in order to get a badge’

Use the acceptance criteria to link to any evidence (for example spreadsheets or diagrams) that support the story.

Epics/features

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.

How to record user stories

Record each user story on a card and give it a title. The cards can be:

Planning with your user stories

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 owner 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 owner 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: