Common mistakes when writing user stories
The user story. A few lines description of who, what and why, accompanies by some acceptance criteria. How wrong can you get it? The answer is quite wrong.
I wrote a post earlier this year where I looked at how hard it can be to write a user story for making a peanut butter and jelly sandwich, following on from seeing a video of a Dad taking exact instructions from his children.
Watching the video made me think about writing user stories and how hard it can be to capture everything you need in order to allow your team to deliver what's needed.
There are some common areas where we all fall down in not achieving the 'perfect' user story.
We don't consider all the options
It's all well and good writing a user story following the perfect flow, but our users aren't perfect and the world isn't consistent.
What happens if the user enters incorrect information? What happens to a scheduled process when there's a public holiday? What happens if we have 1000 entries instead of 100?
A good user story will cover these scenarios.
We make our stories too complex
The other side to not considering all the options is to make our stories too complex. We lose ourselves in the detail and don't focus on the outcomes that we want to achieve. Having too much complexity also removes some of the flexibility we want to provide to our engineering team in determining the solution.
A good user story strikes a balance.
We don't give a clear idea of who we're writing it for
They are called 'user' stories for a reason, but often we write the story with a generic user in mind, even writing "As a user I want ..." in the very first line.
The user is a person, who interacts with your product in a role. They could be a new customer, a free customer, a premium customer. They could be the marketing manager, finance manager or customer success team member.
A good user story creates a picture of who is on the other end of the product.
We define solutions, not goals
What does the person refer to in the story actually want to achieve? What is the expected outcome?
By clearly defining the outcome, we build in flexibility for the engineering team to make decisions and find appropriate solutions, without having to check every single detail with you as the product manager.
A good user story makes the outcomes clear.