User stories

User stories will form the basis of your research. They are descriptions of your users and the reason they need the service you're building.

How to write a user story

User stories should include enough information for your product manager to determine the importance of each story and should include:

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

User story 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?)

The goal is the most important part of a user story because it helps:

• make sure you're solving the right problem
• decide when the story is finished, and a user need has been met.

The NSW Government's Energy Affordability user story is:

As a low income householder, I want to find out how I can claim a rebate so I can save money on energy bills.

Acceptance criteria

This is a list of outcomes to use as a checklist to confirm 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…'.

The acceptance criteria for the Energy Affordability website could be:

• It's done when the user knows how to find out if they are eligible for a rebate
• It's done when the user knows how to claim a rebate

Epic user stories

You can also create longer user stories, known as epics, noting they take longer to develop than the few weeks required for basic stories. Ideally, split an 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. You can use paper cards and post them to your team wall or use a digital platform such as Trello or Pivotal Tracker.

If you have a lot of stories, storing them digitally in Trello or a spreadsheet can be useful. You can then turn them into cards to display when you're ready.