In agile methodology, product development is planned, prioritized, 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 whom they are designing for. Rather than being a series of abstract features, with an effective agile 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, agile 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 project's focus.
A user story is only a few sentences long and should describe a user's desired outcome from the software. Agile user story examples are plentiful online, but to give you a concrete example of 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.
Writing a good 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 accomplishing 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 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 start writing your user 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 personas, what 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 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 by 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 users avenge their Uncle Ben; you want to cover the absolute basics. It should be an exercise in minimalism.
Your team needs to know the "who," the "what," 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 getting 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 and 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, 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. After that, 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 what 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 far from what you intended.
How to avoid this mistake?
Luckily, avoiding this mistake is pretty straightforward. Please 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 will likely 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 develop their own solutions to problems, you still need to keep some things in mind about the end product that 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 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 these criteria. Before your team actually begins working, ensure 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 will do. So, 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 se; 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. Instead, it should always describe a deeper level of information.
As a PM, I want to easily create user stories 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 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.
Examples of bad user stories
To better understand what makes a good user story, it can be useful to understand what a bad one looks like.
Here are some examples of bad user stories, along with a brief description of why they don’t quite work.
Example 1
“As a user, I want a new feature added to the product so it can save me more time.”
What’s wrong with this?
In this case, we’ve got a faceless user, basically zero context, and a very vague story. To improve this user story, we could be specific about the user's persona, add at least the type of feature they’re looking for, and better define their end goal.
Example 2
“As a product manager, I want an AI-powered to-do list so I can get more done.”
What’s wrong with this?
We can see some improvement with this user story — at least we have a persona or role — but there’s still more work to do. This user story clearly focuses on specific features and not goals — the how and not the why. An AI-powered to-do list may be one way to address this story, but that’s up to the development team to decide. This user story is also an example of vague acceptance criteria. What exactly does “get more done” mean? Being specific is essential when it comes to assessing outcomes.
Tips for writing better user stories
We’ve covered a lot of ground when it comes to user story mistakes, so let’s take a moment to summarize what not to do when writing your user stories:
Faceless user: Don’t be afraid to get specific about a user’s persona, motivations, and goals.
Poor context: Be sure to give enough context to ensure that everyone involved understands the user story.
Vague story: Use concise language to describe the user's goal and the value it brings.
Focuses on features, not goals: A keen focus on the user's needs and goals, rather than the specific features of a product, will result in a better user story.
Too broad: Make user stories specific yet narrow enough in scope to avoid overwhelming their target audience.
Vague acceptance criteria: Define acceptance criteria and make sure they are both specific and measurable.
Overcomplicated: Avoid adding redundant details to keep your user stories simple and straightforward.
Lacks measurability: Make sure user stories are measurable so you can measure their success further down the road.
You can also simplify your user story writing by drawing from existing frameworks, like the three C's of writing user stories,developed by Ron Jeffries back in 2001:
1. Card: Write your user stories on physical cards or in a digital platform like airfocus to make them accessible and shareable anytime.
2. Conversation: Make user stories your starting point for discussions between team members and key stakeholders to create alignment across departments.
3. Confirmation: Agree on acceptance criteria to verify that your user stories are complete and meet the specific needs they’re addressing.
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 fine art to writing good user stories. We hope that by exploring these 9 very common (but thankfully very avoidable!) user story 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!
Valentin Firak
Read also
Experience the new way of doing product management
Experience the new way of doing product management