Top 5 User Story Mistakes You Can Make as a Product Manager

In 1998, Kent Beck introduced the concept of user stories as part of Extreme Programming (XP). Beck’s intent with user stories was to encourage conversation and storytelling within software development. User stories remind us to pay attention to the end users we’re building products for (“who”), their objectives and goals (“what”), and the benefit or value they will gain (“why”).

Since then, user stories have become the go-to method for building out a product backlog. They can provide context for teams, helping guide them to solutions based on real user needs, without bogging them down with too much detail. But user stories only offer benefits if they’re properly written and understood. When we don’t take the time to write or discuss them properly, we miss out on the real value user stories can offer.

This article addresses some common mistakes you can make as a Product Manager when it relates to user stories, and some tips to keep you on track.


Mistake #1: Dropping conversation in favour of tools

If a team member starts work on a user story (or any product backlog item) and the team has not had a conversation about it, then you’re doing it wrong! Agile Principle #6 states: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” That means discussing backlog items before unleashing the team on them.

As our tools get better, we tend to rely on them more. But we need to be careful not to rely on them too much. We need to ensure that the buck doesn’t stop at sticking things in Jira or <insert tool of choice>, and that for each and every user story we have a conversation about it in planning and backlog grooming discussions.

Expecting a team member to interpret a user story exactly as you intended it — understanding the “who, what, and why” without actually discussing it — is unfair to that team member. You can bet that when the user story gets into the acceptance or done column, there will be rework needed. Having things get pushed back to to-do when they pass the finish line is frustrating for all parties involved. Our tools should augment our way of working but they shouldn’t replace good ol’ fashion conversation.

Tips for avoiding this mistake:

  • Remember Agile Principle #6. Don’t rely on tools like Jira to do the communicating for you. Encourage face-to-face conversation during sprint planning and backlog grooming sessions.
  • Discuss each and every user story! Don’t skip over them even if they seem simple or straight-forward and remember that points-of-view differ from person to person. What seems simple and straightforward to one person might not be for the next.

Mistake #2: Forgetting to make the conversation interactive

We’ve all been there: you’re part of a long, drawn out sprint planning or backlog grooming meeting, where one person is reviewing the user stories in Jira and maybe half (if you’re lucky) of the people participating are engaged. People start to watch the clock, check emails, and start agreeing with one another just to wrap up and get out of the meeting. It’s a sure sign you’re headed for trouble.

The issue with these types of sessions (besides being super boring), is that we leave them believing that we all understand each other and we’re all on the same page. The reality is that we each bring different perspectives to the table; our individual “knowledge tanks” contain different information. We might think we’re speaking the same language or interpreting things the same way, but our communication styles and vocabulary differ, and the reality is that our understanding of the problem or challenge will differ, too.

That’s why it’s so important to keep meetings interactive. Showing — and not just telling — each other how your understanding of the problem and solution play out are what will keep your team not only engaged with the meeting, but on the same page with plans going ahead.

“Effective story conversations build shared understanding. The best documents use words and imagery to help recall our conversations, but they don’t replace our conversations.” — Jeff Patton, User Story Mapping
Illustration first introduced by ThoughtWorks and then repurposed/rejigged by Jett Patton

Tips for avoiding this mistake:

  • Find opportunities to externalize thinking within the team by using application maps, journey maps, sketches, interaction models and wireframes to support user story conversations. Bringing these artefacts into your sprint planning or backlog grooming sessions can be a great way to detect differences in what the team understands.
  • Bring designers, technologists, and strategists together in sprint planning and backlog grooming conversations. You will see the benefits when these brains with different perspectives are collaborating and working together to solve problems. The discussions that happen regarding user stories, and the outcomes of those discussions, are far more important than the stories themselves.
  • Explore more collaborative techniques like User Story Mapping, or Event Storming to build a shared understanding all while keeping things creative and engaging.
  • Use collaborative tools like Realtime Board if you have remote team members. This will ensure the conversation is inclusive of all team members.

Mistake #3: Taking the lazy road and leaving out the context

It’s 6pm on a Friday, you can almost taste the weekend, and you’re on User Story #120… *Must finish* you think desperately to yourself. And in that state of mind, this is what you create.

As a user, I want a datepicker, so that I can pick from a calendar of dates.

Not great, frankly. Let’s break it down so we can understand why:

  • As a <user>: The user type or persona is not defined. This is not very helpful when we are trying to empathize with the type of person the goal relates to.
  • I want a <datepicker>: This doesn’t tell us what the persona actually wants, only a potential feature that could be implemented. What is the intent, goal or objective? Datepicker implies a solution, and leaves no space for the team to have a conversation regarding other potential ways of handling the goal (see mistake #4!)
  • So that <I can pick from a calendar of dates>: This statement adds no value and just repeats the previous statement. The “why” and the benefit still aren’t clear.

Writing user stories can be tedious and time consuming. But we still need to think critically about the role-goal-benefit for everything we create. Be careful not to fall victim to the lazy road.

Here’s an improved version of that user story:

As a job applicant, I want to choose a date for my interview, so that I can communicate my availability to the hiring team.

Tips for avoiding this mistake:

  • Keep your user stories short, and ensure you have a clear role-goal-benefit structure in place. Focus on “who, what, and why”. If you don’t have clarity into the role-goal-benefit and don’t really understand your users, then you run the risk of speculating about features instead of understanding and building against user needs.
  • Write your stories in the language of the user. Any user should be able to read the story and immediately understand what it means and how it will add value.
  • If you’ve been writing for more than 2–3 hours, make sure to take breaks so that you can revisit things with fresh eyes.
  • Don’t focus on the “how”. Avoid solutioning in your user stories. Leave solutioning for sprint planning where you can collaborate with the team to come up with an approach that works given your various constraints.
  • User stories should produce a vertical slice of working code. Think of layers of a triple decker ice-cream sandwich where different layers represent things like data, backend, front-end, etc — we want to slice through all the cookie, ice-cream ooey-gooey-goodness.
  • Don’t try to jam too much into one story. User stories should be small enough that they can be developed and tested within 1 iteration (1 sprint). Use the I.N.V.E.S.T principles as an input to help assess the quality of your Product Backlog items.

Mistake #4: Too much prescription, not enough creative thinking

Be careful not to get too fixated on format. It is possible to be too prescriptive with your user stories. Avoid attaching high fidelity designs, or writing really prescriptive design or interaction requirements in the story description without discussing the approach first with the rest of the team. User stories should not act as a design or functionality spec.

Tips for avoiding this mistake:

  • Ensure the technical team can vet and review design approaches and concepts before they get into high fidelity, polished screens. In collaborative design studios or ideation sessions, ensure cross-disciplinary perspectives (design, technology, business) are represented in the room.
  • Implementation details should happen at planning or grooming. With each design solution/concept, always come prepared with a low-complexity, low-effort design option as well that you can discuss. Sometimes we need to make trade-offs when it comes to implementation, as we aren’t always able to afford all the bells-and whistles given project constraints. (Example: maybe the user needs to input a date. We may feel that the best user experience is a “date picker”, but this is where we need a conversation. A date picker might be too expensive to develop and implement based on our constraints. Perhaps the goal can be achieved by implementing a less complex solution, like a simple field capture. Have conversations with the rest of the team on how the user goal can be satisfied given the constraints and priorities.)

Mistake #5: Leaving out “Confirmation” and forgetting to define “Done”

This is probably the biggest mistake of them all. Acceptance criteria might be the most critical part of a user story or any product backlog item. It clarifies the conditions that must be satisfied in order for the story or backlog item to be accepted by the users, customer, or the consuming system. As a team, acceptance criteria becomes our contract and how we ground our estimates and commitments. Acceptance criteria will feed into the “Definition of Done” — the global checklist that can be applied to all product backlog items including user stories.

Tips for avoiding this mistake:

  • For every product backlog item, ensure the description contains acceptance criteria. Acceptance criteria is specific to the product backlog item. The goal of acceptance criteria is to ensure the full team has a common understanding of the problem and goals that need to be satisfied, to clarify the effort before the team starts work, and to help team members understand when a story is considered complete. Creating acceptance criteria should be a collaborative effort between the team and the product stakeholders.
  • Sometimes there are specific functional or business requirements we can’t ignore. We should be accounting for this in the acceptance criteria. Requirements can be functions, constraints, or business rules. Think about things like compliance, or security. For example, “not storing passwords in plain text” is a legitimate criterion.
  • Before any work is started, establish and agree as a team on the definition of “Done”. This is the checklist used to review each product backlog item for completeness. Some common coverage includes: Passing peer review, passing code review, passing automated tests, no defects introduced, passing browser testing coverage (it is important to specify which versions of browsers and on which devices), and passing all acceptance criteria. It is also important to note that in some cases there may be different levels of Definition of Done. There could be Definition of Done at the product backlog item or story level, the Sprint level, or the release level depending on the work being completed. Ensure this is established and that there is a shared understanding among team members and product stakeholders.

In Summary:

Phew — that was a lot of pointers! To help you keep these tips in mind, I’ll leave you with a checklist of the main actions you can take to avoid the big 5 user story mistakes. Happy user story writing!

Prioritize conversation

  • Don’t rely on tools to do the communicating for you. Encourage face-to-face conversation during planning, grooming, and refinement sessions.
  • Discuss every user story — even if they seem simple or straight-forward!

Make conversation interactive

  • Documentation and communication doesn’t always work the way you intend. Find opportunities to externalize thinking by using application maps, journey maps, sketches, interaction models, and wireframes to support story conversations.
  • Bring designers, technologists, and business strategists together in sprint planning and backlog grooming conversations.
  • The discussions that happen regarding user stories — and the outcomes of those discussions — are far more important than the stories themselves.
  • Explore more collaborative techniques (i.e. User Story Mapping or Event Storming) to build a shared understanding while keeping things creative and engaging.
  • Use collaborative tools like Realtime Board if you have remote team members to ensure the conversation is inclusive of all team members.

Provide context

  • Keep your user stories short and ensure you have a clear role-goal-benefit structure in place. Focus on “who, what, and why”.
  • Don’t focus on the “how”. Avoid solutioning in your user stories. Leave solutioning for sprint planning where you can collaborate with the team.
  • Make sure to take breaks so that you can revisit things with fresh eyes.
  • Write your stories in the language of the user. Any user should be able to read the user story and immediately understand what it means and how it will add value.
  • Use the I.N.V.E.S.T principles as an input to help assess the quality of your product backlog items.

Invite collaborative and creative thinking

  • In design studios or ideation sessions, find ways to include cross-disciplinary perspectives (design, technology, business strategy)
  • Ensure the technical team can vet and review design approaches and concepts before they get into high fidelity.
  • Implementation details and approach should happen at planning or backlog grooming and refinement. With each design solution/concept, always come prepared with a low-complexity, low-effort design option as well that you can discuss.
  • For every product backlog item, ensure the description contains acceptance criteria. Creating acceptance criteria should be a collaborative effort between the team and the product stakeholders.
  • Before any work is started, establish and agree as a team the definition of “Done”. This is the checklist used to review each product backlog item for completeness.

Thanks for reading— be sure to 👏 and share the article!