9 common user story mistakes most product managers make (and tips on how to do better)
In agile methodology, product development is planned, prioritised and structured as a series of user stories. And not without good reason. Any product manager knows just how critical writing good user stories is in ensuring a product’s success.
A great user story reminds teams who they are designing for. Rather than being a series of abstract features, with an effective user story, product teams can more effectively visualize the importance of those features for their end user, as well as how they can and should fit into their lifestyle.
Done well, user stories reap huge benefits for product development. Done wrong, however, and you miss valuable opportunities to design truly user-centered products.
In this article, we’ll run through 9 of the most common user story mistakes that product managers make, as well as tips on how to do better.
Let’s dive in.
First up, what is a “user story”?
In agile software development, for example Scrum, a “user story” is the smallest component of work within a project. Every user story provides the team with an end goal, with the collection of user stories steering the focus of the project.
A user story itself is only a few sentences long and should describe a user’s desired outcome from the software. User story examples are plentiful online, but to give you a concrete example for the role of a product manager might look like this:
“As a photographer, I want to add new pictures, so I can easily share them with clients.”
This story — rather than simply describing what, also effectively explains the fundamental why a user would like to upload pictures .
How to write a user story?
You may have noticed that the example user story above follows a particular flow. First, it identifies the end user, then it describes what they want/need, and then it explains why they want/need that want/need. A simple template might look like this:
“As a [user], I want to accomplish [goal], so that [need is fulfilled].”
While not completely set in stone, this format should be the basic structure of every user story. Your user stories may be a little longer than this, but each story should focus on one kind of user, generally one goal, and a fairly specific reason for wanting to accomplish that goal.
While this template may seem simple, it can be surprisingly difficult to stick to, especially when you’re new to creating user stories.
Here are some of the most common pitfalls that product managers fall into.
1. Having a faceless user
First up is the dreaded Faceless User.
“But wait,” you ask yourself, “if these user stories are made up, aren’t they all faceless?”
Well, not really. Yes, the user stories aren’t based on actual people, but they should be based on actual people’s needs, roles, and goals.
If you simply call your user, “the user,” then you make it hard for your development team to understand that person’s motivations. The user in each user story should be more than just a vessel for the story. Otherwise, you might just be making up a user story to shoehorn in an unnecessary feature.
How to avoid this mistake?
A good way to avoid having vague users in your user stories is to create a list of personas. You typically will have a few types of end users in mind, so create a background for each of those users before you start making your user stories. Then, when you do start writing your stories, you’ll know who each one is about and if it really needs to be written.
If you’re new to this, here’s a simple guide to personaswhat they should include and how to create them.
2. Explaining the “how” and not the “why”
A common problem that product managers have, especially when they’re new to writing user stories, is that the story can easily become a way of simply describing a feature you want to be implemented rather than a story explaining a user’s needs.
The result is a user story that is overly technical and focused on specifics, reading more like a description of the software than a story. If you’re just converting a laundry list of software features into a story format, you’re writing your user stories wrong.
How to avoid this mistake?
Fortunately, this mistake can be avoided simply critiquing your own stories and having an open mind. Read your user stories after writing them, see if they focus too much on specifics, and be open to criticism from your team if they point this issue out to you.
3. A long and vague story
On the opposite end of being too technical is being too vague. Even though “story,” is in the name, this isn’t a writer’s workshop. You’re not trying to explain how this software will help the user avenge their Uncle Ben; you just want to cover the absolute basics. It should be an exercise in minimalism.
Your team needs to know the who of your story, the what of your story, and the why of your story — and that’s it! Often, there should only be one of each of these things in every story.
How to avoid this mistake?
The easiest way to tell if your story is too long is if you get bored before you finish reading it. A more strategic approach, though, is that if you find yourself with a long user story, start breaking it down.
Rather than throwing pieces of it away (unless they’re truly pointless) split the story into several stories. This will make the intentions more clear to your team as well as make each story more manageable during development.
One of the most effective ways of making sure you’re hitting the right level of detail (and planning them in the right order) is to do user story mapping, which is a technique devised by Jeff Patton. Using this technique, you map out the end-to-end experience of a user and how they interact with your product along the way. This helps you think of features as tasks that the user completes.
This post details everything you need to know about effective user story mapping.
4. Providing poor context within the user story
This mistake usually starts to sink in after you’ve already ground out the first fifty user stories. Every story starts to look and sound the same to you, and your brain is shutting down at the idea of writing user story fifty-one. This is when you end up with a story like this:
“As a content manager, I want a text editor so that I can edit text.”
While this technically follows the right template for a user story, it doesn’t tell your development team anything other than that you really want the software to have a text editor.
How to avoid this mistake?
You want to keep your stories short and simple, but also purposeful. Focus on who the user is and they would actually want, not what you want them to want. The what and why of your user story should not be the same thing.
If you’ve been writing user stories for more than a few hours and can feel your brain shutting down, don’t hesitate to take a break and revisit with a fresh perspective.
5. Assigning a story without discussing it first
Breaking out of the actual story-writing process, let’s get into how your team is actually going to receive their story assignments. This is just as crucial as writing the stories — if not more — as your team is going to be interpreting the stories during the development process.
More specifically, since they’re not writing the stories, the best your team can do is use their interpretation of each story. And if you assign the stories without going over them with each team member, those stories could be wildly misinterpreted, resulting in an end product that is far from what you were intending.
How to avoid this mistake?
Luckily, avoiding this mistake is pretty straightforward. Don’t neglect to go over the stories with your team when assigning them. Have a meeting, present the stories with your intended meeting, listen to feedback and make sure that everyone is on the same page before work begins.
6. Not engaging the team in the story-creating process
Continuing with our team-meeting trend, a mistake that’s easy to make is having your story-assigning process simply be, well, a story-assigning process. If all you’re doing is explaining your intentions and stories, you’re going to end up with a severely lacking finished product.
The purpose of creating user stories in the first place is to avoid having a team that’s focused solely on doing what you ask, and instead to have a unified focus on the end user’s needs. If you alienate your team from the story creation process, you are likely to end up with a team that is bored with and disconnected from the entire project.
How to avoid this mistake?
The best way to avoid this user story mistake is to have an open mind when presenting your stories. Foster a team culture where feedback, criticism, and opinions are welcome. Rather than seeing your team meetings as you doling out assignments, think of it as a collaboration session between your initial ideas and the team’s unique perspective.
7. Vague acceptance criteria
While you want to leave enough creative liberty with each user story that your team members can come up with their own solutions to problems, you still need to have some things in mind about the end product needs to have implemented.
Your acceptance criteria should contain the things that the customer/end-user needs from the software being developed. Without any acceptance criteria, there’s no real way to measure when the project is finished or if it is even what the client is looking for.
How to avoid this mistake?
The user stories shouldn’t replace your acceptance criteria, but rather inform how you accomplish this criteria. Before your team actually begins working, make sure that a final criterion has been created and agreed upon. From there, you can come up with user stories to guide the creative process.
Your team needs a clear end goal (your acceptance criteria) and a way to get there (your user stories).
8. Using “so that [feature]…” instead of “so that [goal]…”
Let’s revisit our user story template real quick:
“As a [user], I want to accomplish [goal], so that [need is fulfilled].”
We’re going to hone in on that last section, “so that…”. This segment of the user story formula is not where you describe what the software is going to do. For example, if your user story looks something like this:
As a product manager, I want to find information about user stories, so that I can write user stories.”
… then you’re not really writing a user story correctly — you are close, though.
The “so that…” portion should tell you why the user (in this case, you) wants to accomplish said goal.
How to avoid this mistake
In the above example, the why isn’t to know how to write user stories per say; it’s to know how to write them so that you can effectively communicate user-centric features to your product team.
The why should not be the what rewritten to sound different. It should always describe a deeper level of information.
As a PM, I want to easily create user stories in order to explain product features, so that my development team and designers can implement them easily
To avoid making this mistake, take the time to reread your stories with a critical and fresh eye. If you’re having a hard time distinguishing between the two, don’t hesitate to bring in an outside opinion before finalizing your stories.
9. Removing creativity
And last but certainly not least, your user stories should not remove creativity from the project. In fact, that’s the exact opposite reason of why we use user stories to begin with.
The entire idea of using these stories is to inspire unique, outside-the-box thinking among your team. If all your user stories do is tell your team what to do in a narrative format, you could save yourself the trouble of writing them in the first place and instead create a list of what you want them to do.
How to avoid this mistake?
If you want to maintain a creative atmosphere throughout the user story process, keep the stories flexible and your team involved. Be open to changes, suggestions, insights, and alternative perspectives.
Having a team not only provides you with a workforce to accomplish a project’s goal, but also a handful of unique and valuable outlooks on what the final product should be. So embrace the diversity within your team and allow your user stories to adapt and evolve with your team’s feedback.
Conclusion
As we’ve discussed in this article, user stories are a powerful tool to help any product team know not just what they are building, but why they are doing so. Most importantly, when coupled with effective acceptance criteria, they empower your team to know when a task or feature is “done”.
However, as we’ve also seen — there is a very fine art to writing good user stories. We hope that by exploring these 9 very common (but thankfully very avoidable!) mistakes, that you can avoid falling into the same pitfalls.
Remember, poorly crafted user stories have the potential to derail product development, so investing the necessary time and effort to do them well will pay dividends over the course of your development life cycle.
Good luck, and enjoy!
Originally published on the airfocus blog. airfocus is the most powerful way to prioritize what to do and build more effective roadmaps.
