11 Common Mistakes When Creating User Stories
11 Common Mistakes When Creating User Stories
More User Stories, More Problems
User Stories are not the solution. They are the problem.
Reread the above sentence and allow it to sink in.
The sentence may confuse you initially, but it should make sense after you finish reading this article.
User Stories are extremely popular. Almost every team I join uses them and they are as popular as using Story Points. And almost every Product Backlog I examine they are being used the wrong way.
Instead of talking about how you should apply User Stories, it’s much easier to talk about how you shouldn’t use them. Then, it will immediately become much clearer how you should be using them.
Let’s get started!
1. Using the User Story As the Product Backlog Title
The picture below is actually from Jira's documentation. Try to read all these User Stories.
Oh, snap! You can’t do that because many of them are cut short as they’re too long to be displayed. Too bad.
After scanning the Product Backlog, you should be convinced that a list of User Story titles is exactly not how you should go about it. Just because you use a User Story for a Product Backlog Item doesn’t mean the title has to contain the full User Story.
Try to invent a short title that captures the gist of the User Story. Then, if you want to know more details, you can read the actual User Story. Remember, the title is simply a hook to remember what you talked about. The title doesn’t have to express everything you know. Don’t make everything you know an obstacle for remembering something.
When you do make the work on your Product Backlog scannable and easy to read, then you make your Product Backlog transparent and easy to understand. Clogging the Product Backlog with User Story sentences will fill your Product Backlog with noise irrelevant to providing the big picture of what you will be working on.
2. Expressing Everything as a User Story
If everything in the Product Backlog is a User Story, you can be sure the team uses User Stories incorrectly. User Stories are vehicles that enable conversation about the User and what they are trying to achieve.
User Stories are not so great when you’re using them as a vehicle to express your solution, which brings me to my next point.
3. Using User Stories When You Didn’t Talk to a User
User Stories are supposed to be actual stories about the user. It’s not good enough to conjure them out of thin air by imagining what you believe your users will need. User Stories should be rooted in evidence and actual conversations with your users.
Remember, if it’s not a Story you’re telling about an actual User rooted in the real world, it’s not a User Story but a User Fairytale.
4. Whoever Asks For the Feature Is Included as a User In the User Story
We’ve all seen these User Stories:
“As a Developer / Product Owner / Scrum Master / Tech Lead / Software Architect / Insert any possible role that exists in the organization here.”
The person who asks isn’t the User in the User Story unless they are the User who will be using your product. This also applies to technical User Stories, which brings me to my next point.
5. Don’t Use User Stories For Technical Tasks
User Stories are not meant to express technical work. User Stories are meant to enable conversation about the problem we’re trying to solve for a specific user. If you already know the problem you’re trying to solve, and it has nothing to do with your users, then don’t use a User Story to express your solution.
Use a Problem Story or an Improvement Story instead. Or don’t use a template at all and provide the relevant context.
6. Reverse Engineering the User Story From a Feature
Let’s say it’s been decided that you will build a certain feature, but you didn’t even talk to any users. Then don’t reverse engineer the User Stories from the feature. Don’t use User Stories, as you’ll be making them up, and they become User Fairytales that don’t add any value.
User Stories are not supposed to make you think. If you need to think long and hard about what you need to put in a User Story, then the problem isn’t the template but your understanding.
User Stories are supposed to be a vehicle for capturing your current knowledge and understanding that’s rooted in evidence and/or actual users. The moment you’re struggling to express it as a User Story, you can be sure that you’re doing something wrong.
7. Splitting Up User Stories as More User Stories
I started this article with User Stories are not the solution, they are the problem. That’s because User Stories start with what your user is trying to achieve. The User Story should be agnostic regarding the solution because then you have the freedom and understanding to discover the best solution.
The moment you have a User Story rooted in actual understanding and knowledge about what your user is trying to achieve, then the moment you start splitting it up into User Stories, you may turn your User Stories into a vehicle for requirements. That’s not the purpose or the point of User Stories.
Keep the work rooted in the original User Story that tells a story about the user. When you split up the work, express it without a template or from a solution perspective linked to the original User Story.
Your User doesn’t want to click a button. They want to achieve certain things. If they can do that without clicking a button, that’s great too! When you make User Stories no longer agnostic to the solution and use them as a vehicle for describing the solution itself, you lose the benefit of User Stories, and it’s wise to use something else instead.
I want to stress that the acceptance criteria may talk about the solution itself, but the User Stories should be agnostic to your solution.
8. Not Writing User Stories Collaboratively
User Stories are supposed to be a vehicle that enables conversation and talking about the best solution to enable the User Story. When you throw a User Story together with acceptance criteria over the fence to your team, that’s the best way to halt discussions and silence exploration.
A much better approach is to start with a User Story without acceptance criteria and to explain the context and what the user is doing and trying to achieve. Then, we can explore potential solutions and describe them in the best way possible.
And when you do that, whatever you write down becomes a reminder of what everyone already knows.
9. Not Including the Relevant Context
Context matters. User Stories are lightweight and don’t allow capturing all relevant context. Add the relevant context to the User Story just like you would when writing acceptance criteria for that User Story. Set the stage so you set people up for success. Best of all, do it in a conversation so everybody is on the same page.
10. Value For the User Is Unclear
What is the user trying to achieve? Why are they trying to achieve that? How will it grant them progress in their lives? Remember, just because the User Story is a single sentence doesn’t mean that their situation and how they’re looking to achieve value isn’t multifaceted. Don’t limit yourself to what fits in the User Story. Try to tell the whole story of the user, not just what fits in the template. Which brings me to my final point.
11. Forcing the User Story Template
User Stories offer a convenient template. However, alternatives such as Problem Stories, FDD, Job Stories, and Improvement Stories exist. It’s more important to capture the richness of your conversations or the deep level of your understanding rather than to force adherence to any format.
User Stories Provide the Bare Minimum
The User Story template is a convenient shortcut so you provide the bare minimum your team needs. If you understand why it’s the bare minimum and why the template is formulated the way it is, then you don’t have to use User Stories.
At the end of the day, the User Story template reminds you of the bare minimum you should provide to the team. And when you understand how the specific format provides the bare minimum, then you’re free to let go of the format.
All that matters is that the relevant details are present for the team to understand what we’re trying to achieve and why it matters. A much better way to achieve that understanding is by doing a Story Mapping session together rather than throwing some User Stories over the fence.