Writing user stories

I've been looking again at user stories recently, and had a chance to reflect on why they're useful (and why they are difficult to get right). As I wrote in my weeknotes last month… "the middle bit is quite easy to write, the user groups are a little more difficult, and the “so that” bit is really difficult".

Here are some notes that I pulled together on how to write better ones (borrowed heavily on the excellent advice in the GOV.UK Service Manual).

Format

  • As a… [who is the user?]
  • I need to… [what does the user want to do?]
  • so that… [why does the user want to do this? What is their goal?]

Tips

  • User stories are tasks that users must complete, or knowledge they must acquire to inform a decision.
  • A user in this case does not have to be just one person. It can mean a broad group of people.
  • User stories should be specific to a person or group of people (to as low a level of granularity as is practical) and to a moment in time.
  • Try to write from the users‘ perspective. Use the same language that users would use.
  • Try to describe the problem, not the solution.
  • If you need to add more detail, try writing acceptance criteria. A list of points that indicate when a user story is complete.

Further reading

Contains public sector information licensed under the Open Government Licence v3.0.