The most common User Story mistakes - Scrum Guide

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:

Introduction
Problems with 3W
Problems with 3C
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?

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

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.
View all posts