User stories are the strongest way you can capture requirements for your digital service and are another key component in taking a user centric approach to design.
Rather than the old way of doing things, of producing a specification document outlining every single feature that a product needs to have, user stories focus on the needs of the users of that product, and specifically on their outcomes.
This focus goes a long way towards producing services that are usable and deliver end to end, rather than breaking down halfway through because a feature ‘works’ technically, but doesn’t do what is expected or needed.
Additionally, user stories can be a great way to bring a product to life when describing it to stakeholders. It really demonstrates a new way of talking about digital services and technology, and can be very meaningful to non-technical folk, giving confidence that you’re doing the right thing.
In a multi-disciplinary team, the user stories are usually the domain of the product manager, written with the input from the rest of the team. If you don’t have all the roles in your team, then do try to have a single person responsible for the compilation of user stories – and try to have someone non-technical doing it, to avoid the temptation to leap into solutionising too soon.
Writing a good user story follows a certain format:
- As a…
- I need to…
- So that…
For example:
- As a new, and busy resident who drives to work in the town centre
- I need to apply for a parking permit online
- So that I don’t run up loads of parking fines
That’s quite a high level example (often referred to an ‘epic’ story), so we can probably come up with a more granular user story:
- As a resident who has applied for a parking permit online
- I need to be proactively kept informed of the progress of my application
- So that I don’t need to keep contacting the council
Note that the user story doesn’t explicitly state here what the solution is. The focus is on the outcome that the user needs, not the technology that will enable it.
The technology is likely to be mentioned in the second main element of a user story, which is the acceptance criteria. These are descriptions of what done looks like for this story. The GOV.UK Technology blog shares a nice method for writing good acceptance criteria, based on the pattern ‘Given… When… Then…’.
Additional information for a user story might include the prioritisation of that story, so the team know how important it is to get that story completed, and also the size – how much effort is likely to be needed for the story.
Here’s some tips for writing good user stories:
- Keep them small. If they start getting to wide in scope, treat them as an epic and break them down into smaller stories
- Avoid the temptation of repeating your ‘I need to’ in your ‘So that I can’ – which is a really common error. For instance – ‘As a manager, I need to access my team’s performance dashboard, so that I can view the perform dashboard’
- Don’t treat individual technical pieces of work as user stories. They might be important to the project, but that doesn’t mean they directly contribute to meeting a user need, and doing so can clog things up and spread confusion about what the outcome of the project is intended to be
- Try following the INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) formula for producing good user stories. It’s a handy framework to ensure your stories are what you and your users need. Read more about that here.
To make life easier, here is a simple template for writing user stories. Feel free to amend it any way you like!
Hope it’s useful!