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).
- 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?]
- 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 (e.g. a persona).
- User stories should be specific to a defined persona (to as low a level of granularity as is practical) and to a moment in time.
- Try to write from the user’s perspective. Use the same language that users would use themselves.
- 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.
- Writing user stories on the GOV.UK service manual
- The test of a good user need poster – PDF 433KB by Leisa Reichelt and Ben Holliday
Contains public sector information licensed under the Open Government Licence v3.0.