Mistakes Product Managers Make When Writing User Stories
Avoid these mistakes!
Join the DZone community and get the full member experience.Join For Free
You may also like: Best Practices to Succeed With User Stories
Everyone wants to go Agile today. Teams want to put the user in the center of their product development process while building products. After all, you are building the product for your users, right?
User stories are one of the basic tools that help teams keep the user in mind while defining the product and its features.
A lot has been talked about how to write user stories.
I can certainly understand why they’d prefer other variations.
A lot of times when writing user stories, we think we are writing from the user’s perspective, but we end up skewing it with our biases and knowledge.
In this article I will talk about some of the common mistakes teams make when writing user stories that cause this confusion.
1. User Stories That Are Too Broad
When user stories are too broad, crucial information regarding the expected action and the need can get missed out.
If there are a lot of “ands” or “ors” in your team’s user stories, it is a good indication that it is too broad and you should consider re-writing it. Also, there’s a very good chance that your too broadly written user story is actually an epic.
2. User Stories That Are Too Fine
When user stories are broken down too fine, you begin talking about how you are going to implement it. This removes the focus from the user and leads to poor communication of expectations within the team.
3. Not Being Negotiable
User stories are not meant to be a specific, precise description of a feature, and it must not be fixed in stone.
Here’s a classic scenario to identify if your user stories are too rigid:
Sometimes a user story may have been written in a particular way, and your team finds it uneasy to implement because there’s an easier alternative. In cases like these, the team should be willing to compromise on the approach provided it doesn’t hurt the value a user derives.
4. Reiterating the User Story in Acceptance Criteria
Acceptance criteria allow you to describe conditions that need to be met for the story to be marked as completed. It ensures that you gather feedback, help the team plan, and track their work. It makes the user story more rich, precise, and testable.
5. Having an Undefined User
It can feel silly to mention the user persona in every user story, but it can add a tremendous amount of value in terms of the outcome. This particularly is important if your product has more than one user persona.
There will, of course, be features that’ll get built specifically to different personas. If you want your team to be more aligned with the outcome you are expecting out of them, they need to know who the end-users are and what benefit they’ll get out of the feature.
6. Poor Context
Far too many times, we end up writing user stories for the sake of it. After a point, nearly every user story starts to look the same.
Eg: "As a content manager, I want a text editor so that I can edit text."
All this tells your team is that you want them to build a text editor and nothing else. If you’ve been writing down a bunch of user stories for a while, it’s best to take a break and revisit it with a fresh perspective.
Sometimes, even after a break, you might not be able to come up with something more meaningful. This can be a good indicator that you need to talk to your users more and understand their needs better. There’s really no point trying to squeeze it out of your brain.
Although using a user story template can be useful, it is never as simple as just trying to fill it. Writing a user story is a bit like an avalanche. One mistake while writing user stories often leads to a series of other mistakes as a by-product. All it takes is one tiny mistake in the process and you could find yourself in a pile of mess.
Opinions expressed by DZone contributors are their own.