About airfocus

Try for free


9 Common User Story Mistakes Most Product Managers Make

11 Jun 20199 mins read
Valentin Firak
9 Common User Story Mistakes Most Product Managers Make
By Valentin Firak

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. 


Get started with
ready-made templates

Find template
airfocus templates

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. 

Download now: Get our 5-minute guide on How To Use the Story Mapping Method

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 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.

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. 

Download now: Get our 5-minute guide on How To Use the Story Mapping Method

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. 

Product Digest newsletter signup

Cut through the clutter of
PM Content with our
bi-weekly digest

Sign up

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. 


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 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!

airfocus templates
Get started with ready-made templates
Find template

Read also

Testimonial Company
Product Management 27 Jan 2023
5 Best Tools for Product Owners
Product owners need to have the right tools to help them manage and prioritize their work, as one of the most important links in the scrum team's chain. Here are 5 tools for product owners.
By Quadri Oshibotu
Testimonial Company
Testimonial Company

Experience the new
way of doing product

Try for free

Book a demo

airfocus modular platform
Top rated
on major review platforms
g2 badge users love us
g2 badge leader fall
GetApp badge category leader
software advice badge
capterra shortlist badge
proddy badge roadmapping
crozdesk badge
All rights reserved.