User Stories describe how a new Product functionality works in everyday or business language. However, their preparation takes a lot of time, effort, and thinking. In today’s entry, we point out the most common User Story mistakes and suggest how to deal with them.

The most common User Story mistakes – table of contents:

  1. Introduction
  2. Problems with 3W
  3. Problems with 3C
  4. User Story mistakes – Summary

Introduction

User Story can be a great tool for motivating the team to propose new solutions to problems presented from the user’s perspective. We wrote about what User Story is in a separate entry. And in this article, we introduced INVEST, which is a popular method of writing good User Stories. Today we will focus on User Story mistakes.

Problems with 3W

A proper User Story answers the questions:

  • Who? (Who is the target user of the Product?)
  • What? (What capabilities have the Product, and what can it do?)
  • Why? (What purpose does it serve?)

However, problems may accompany the answers to each of these questions. The least common problem is the doubt about what should change in the product in response to the customer’s needs. Therefore, we will focus on problems concerning Who? and Why?

user story mistakes

Who – user persona

One of the most common mistakes made when creating User Stories is not answering the question precisely enough: for whom? In other words, who is the user for whom the planned change is intended?

Often a generic response pointing to the Customer or End User as the recipient of the change is not enough. The solution to this problem is to imagine the recipient as a specific persona. A persona is a model image of the target customer. In other words, a persona is a representation of the person who will use the Product in a specific way.

After analyzing your User Story, you may find that it tells the stories of different people at the same time. If there are many target users, it’s worth considering splitting the User Story into smaller fragments to avoid contradictory, mutually exclusive, or simply ineffective actions.

Why? – a poorly defined goal

Sometimes the last section of the User Story becomes the source of problems. It should specify the business value of the changes made during User Story execution. Take a look at an example of User Story mistakes where the description of additional functionality replaces the goal:

As a customer, I want to buy a magic wand with one click because I want to buy a flying carpet next week.

Instead of giving the reason for buying the magic wand, this User Story adds another item to the potential customer’s shopping list. Therefore, when preparing a User Story, don’t forget about the reasons for alterations in the functionality of the Product.

Problems with 3C

We can break down the process of working with User Stories into three stages called the 3Cs:

  • Card – The card on which the User Story is saved
  • Conversation – A conversation within the Scrum Team about the User Story card
  • Confirmation – defining acceptance criteria confirming that a task has been completed

Errors can occur on any of these, which we describe below.

Card

The memory card which stores the User Story has a limited capacity. Therefore, the most common problems concern the length and volume of the User Story. The User Story needs coherence and no beating around the bush, as they say, to such a precise degree that every word counts.

This is because the problem of the User Story card has two dimensions. One is the way it is formulated: concise and containing a necessary minimum amount of enumeration. The second is gthe actual size of the User Story. One general sentence can express a huge number of tasks that cannot be completed during a single Sprint.

Conversation

The one-sentence formulation of the User Story is the starting point for a conversation with the Development Team. Therefore, it is incorrect to treat it as a description of the task to perform. It disables the possibility of negotiations and discussion on various ways of its implementation. User Story should not be treated as a description of requirements for new product functionality, it is rather an invitation to start a conversation about specific technical solutions that will lead to the realization of business value defined by User Story.

Confirmation

We wrote about the acceptance criteria that must be defined for each User Story in detail in the text describing what a User Story is. One of the common mistakes, however, is the lack of vagueness of performance criteria.

A well-written User Story contains a description of the situation in which it is implemented. Its test is that the User takes advantage of the new functionality created by the Development Team.

A useful tool for validating the User Story is to develop an acceptance test. This is usually on the other side of the card containing the User Story.

User Story mistakes

User Story mistakes – Summary

When preparing and applying User Stories, it is worth sticking to the following rules:

  • Precisely identify the User affected by the change
  • Clearly define the purpose of building new product functionality
  • Keep its Volume as short as it can get
  • Treat User Story as a starting point for solution discussions with the Development Team
  • Establish clear rules for acceptance

If you like our content, join our busy bees community on Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Scrum Guide | 21. User Story mistakes caroline becker avatar 1background

Author: Caroline Becker

As a Project Manager, Caroline is an expert in finding new methods to design the best workflows and optimize processes. Her organizational skills and ability to work under time pressure make her the best person to turn complicated projects into reality.

Scrum Guide:

  1. Glossary of basic terms, roles and notions
  2. What is Scrum?
  3. Scrum values
  4. How to implement Scrum in your company?
  5. Scrum Team - what is it and how does it work?
  6. Who is a Product Owner?
  7. The most common mistakes of Product Owner
  8. Who is the Scrum Master?
  9. Characteristics of a good Scrum Master
  10. The most common mistakes of Scrum Master
  11. What statistics and metrics should the Scrum Master track?
  12. Cooperation between Product Owner and Scrum Master
  13. Development Team in Scrum
  14. The most common mistakes of Developers
  15. Scrum artifacts
  16. Scaling Scrum
  17. Sprint Backlog
  18. What is the Product Backlog?
  19. What are User Stories?
  20. Creating the best User Story with INVEST
  21. The most common User Story mistakes
  22. User Story Acceptance Criteria
  23. Estimation and Story Points in Scrum
  24. Planning Poker
  25. Team Estimation Game
  26. Defining Increment
  27. Scrum events
  28. What is Sprint in Scrum?
  29. Scrum Team Commitments - Product Goal, Sprint Goal and Definition of Completion
  30. What is a Burndown Chart?
  31. How to create and interpret a burndown chart?
  32. Advantages and disadvantages of the burndown chart
  33. Kanban boards in Scrum and Scrumban
  34. Velocity in Scrum - Speed of the Development Team
  35. Daily Scrum
  36. Sprint Planning
  37. Sprint Review
  38. What is a Sprint Retrospective?
  39. Common mistakes during a Sprint Retrospective
  40. Product Backlog nurturing