How to Write Good User Stories
A question that comes up a lot is how to write good user stories. I can only assume because people have seen many examples of bad user stories out there.
“We can’t use ‘user stories’ for our type of work. Its too complex and the user stories don’t contain enough detail”
“Why can’t you use user stories?”
“Because we cant build a system from 50 one-liners!”
Uh-oh. Maybe you have seen this situation before, maybe you have been in this situation before either as an engineer or as a product owner. Either way, its a tough spot to be in. Here are some times on how to write good user stories.
Tip 1. There is no story without a goal. Start by outlining the goals of the users in the system.
Remember, user stories describe functionality in terms of the outcome, or the goal of the user. Once you understand what the user is trying to achieve, it makes it much easier to create a good user story.
Tip 2. Include metadata or other artifacts with the user story.
There is a misguided conception that a user story can ONLY include the user story, and not additional artifacts as needed.
Realistically, you are still able to use anything and everything valuable at your disposal to help with the communication process. User stories are the beginning of the conversation, but not ALL communication.
Tip 3. Make sure you have a set of cards with the different user personas described. If you don’t have them, make some.
One of the reasons user stories do a poor job of communicating is because all users are treated the same. How many times have you seen “as a user…” on a user story? However, there is no system of a non-trivial size that does not have multiple types of users. Understanding who those users are, what their pain points are, and how we can address those pain points goes a long way toward being able to write good user stories for those users.
Tip 4. Involve the customer in writing the stories.
When we sit down to figure out what needs to be done for the user (aka the customer), we often shy away from involving the customer in those conversations. This is because we think we should know everything. While we should be aware of the customers needs and goals, the best way to get that information directly is to talk directly to the customers about their wants and needs. Even better, if you can involve the customer in writing the user stories (at least the high level description), you stand a much better chance in delighting the customer with the product.
Tip 5. Keep the stories short, remember, they’re just reminders to have the conversation.
User stories have 3 parts, the card, the conversation, and the confirmation. The conversation is the most important part. This could mean conversations with stakeholders and customers to outline what they want, AND it includes conversations with the team to articulate the business need. There is no substitute for talking, and one of the positive aspects of Scrum is that it shifts the focus from documenting customer needs to actually talking about them. As a product owner, part of your “secret sauce” is to be able to communicate a vision, in both the big sense and the small sense.
Some of the challenges teams have with writing and consuming user stories can be avoided by not having a rigid idea of what a user story is. The user story is just a starting point for the all-important conversation. Then you can flesh out and add details to reflect the shared understanding. What kind of problems do you have with writing good user stories?