3 Levels of User Story Quality
Today, I sat down to mentor a product manager just beginning his journey, and he asked me how I would write a user story. I gave him three examples. Please note, I made these up on the spot, so details may be limited.
As a user, I need a filter so that I can filter on stuff.
As a senior citizen with poor vision who has difficulty using technology, I need a filter so that I can find my grandchildren’s cat photos and share them with my friends.
As a senior citizen with poor vision that has difficulty using technology, I need the ability to find my grandchildren’s cat photos and share them with my friends
Which of these do you prefer? And which of these do you see the most often? I absolutely prefer one of them, but it also depends on the context.
As a user, I need a filter so that I can filter on stuff.
I see examples of this all the time. The "user" is some abstract concept thrown in to fit the format of a user story, so going deeper into the user feels like a waste of time. The reason for a filter is also a waste of time. The intention of this kind of story is to build the thing. These kinds of stories are often complemented by long lists of requirements suited for QA testing and mockups showing exactly what's expected. It's also a sign of an organization that is output oriented.
One additional word of advice: User stories are NOT meant for following requirements. Something like Gherkin Syntax is much more effective in this case. User stories are meant for opening up creative problem-solving and conversations around customer needs. If your team isn't empowered to do that, then it's a waste of time.
As a senior citizen with poor vision who has difficulty using technology, I need a filter so that I can find my grandchildren’s cat photos and share them with my friends.
This is the second most common form of user story I see. Now we have a much deeper context of who the target user is, and surprise, that context matters a lot. You also have a much better idea of what the point of this filter feature is; the need it solves for the user.
This kind of user story helps developers get in the minds of the user and create solutions that are much more tailored to their needs. The product team clearly has more autonomy and room to innovate. And design work happens alongside technical strategy improving the overall functionality. Please note though, this also means putting the story in front of the designers and developers earlier.
As a senior citizen with poor vision that has difficulty using technology, I need the ability to find my grandchildren’s cat photos and share them with my friends
This is the kind of user story I look for with really great product teams. Notice that the story spells out who has the problem, what they need for their problem to be solved, and why they need that problem solved. Instead of talking about functionality, it talks about capability. The story is focused on customer outcomes, not on solutions. And this is when a user story's value really shines.
Great product teams can use these stories to understand the situation of the customer and then think very creatively about what kinds of solutions would work best. It allows developers to consider many different skills and experiences and opens up the door to solutions that are not just software (software, by the way, is a very expensive and slow way of developing solutions).
However, to use these kinds of stories effectively, the product team must be trusted with full autonomy, have their success measured on outcomes instead of outputs, and have sufficient collaboration skills to work towards these solutions together. They must also be vested in the outcomes because they will be needed to explore solutions in advance, which takes time.
I would love all teams to use these kinds of stories, but not all teams or companies are ready for them. That said, we can take steps today to move towards it.
