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:
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?
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.
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.
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.
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 – 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
- Glossary of basic terms, roles and notions
- What is Scrum?
- Scrum values
- How to implement Scrum in your company?
- Scrum Team - what is it and how does it work?
- Who is a Product Owner?
- The most common mistakes of Product Owner
- Who is the Scrum Master?
- Characteristics of a good Scrum Master
- The most common mistakes of Scrum Master
- What statistics and metrics should the Scrum Master track?
- Cooperation between Product Owner and Scrum Master
- Development Team in Scrum
- The most common mistakes of Developers
- Scrum artifacts
- Scaling Scrum
- Sprint Backlog
- What is the Product Backlog?
- What are User Stories?
- Creating the best User Story with INVEST
- The most common User Story mistakes
- User Story Acceptance Criteria
- Estimation and Story Points in Scrum
- Planning Poker
- Team Estimation Game
- Defining Increment
- Scrum events
- What is Sprint in Scrum?
- Scrum Team Commitments - Product Goal, Sprint Goal and Definition of Completion
- What is a Burndown Chart?
- How to create and interpret a burndown chart?
- Advantages and disadvantages of the burndown chart
- Kanban boards in Scrum and Scrumban
- Velocity in Scrum - Speed of the Development Team
- Daily Scrum
- Sprint Planning
- Sprint Review
- What is a Sprint Retrospective?
- Common mistakes during a Sprint Retrospective
- Product Backlog nurturing