edelsprint

What are User Stories?

2020/10/05

Scrum teams develop products for their customers. Therefore, they have to find a way to formulate customer needs in a way that is understandable for all parties involved. User Stories are used for this purpose. In this post, we explain what User Stories are and how they work.

The idea behind User Stories is to understand the view from the user’s perspective and to be able to put yourself in the user’s shoes. If you understand the user, the product can be developed in a way that offers them the most value. In addition, the use of user stories always makes sense if you want to understand the user’s needs and expectations of the product. In short, user stories make the requirements of the product clear. They also invite discussions about the customer’s expectations, since user stories can be worked on together with the customer. That way, the Scrum team learns what the customer really wants.

What’s the origin of User Stories?

The origin of the user stories lies in agile software development. More precisely, in “Extreme Programming” (XP) and in this context User Stories were created by the software developer and author Kent Beck. At that point, User Stories were “only” real stories from the customer’s perspective, i. e. stories in which a customer describes a real problem for which he would like to have a solution. However, at that time, the formulation regarding the length and content of such stories was not regulated. Such a formulation framework was only added later by developer Rachel Davies. In this way she wanted to prevent User Stories from becoming too large and thus too complex. According to Davies’ template, User Stories consist of three essential elements (“role”, “feature”, “benefit”).

This is how it is formulated: “As a [role] I want [feature] so that/because of… [benefit]” or “To achieve [benefit] as a [role] I want [feature].”

The elements of the User Story clarify the most important questions from the point of view of the development team:

If a requirement cannot be formulated in a User Story, this usually indicates that it has not really been understood. In this case, the team should meet with the customer again.

How do you work with User Stories?

Once a User Story has been prepared, it is supplemented by concrete acceptance criteria. These criteria describe when a User Story has been successfully implemented, i. e. they define the technical requirements for the product. They describe what the product should have in order to offer added value to the customer?

Here is an example: Let’s assume the User Story is: “As a freelancer, I want to plan my assignments so that I have a better overview of them.” Possible acceptance criteria for this would be “Have a work calendar,” “Enter job start/end date,” “List daily tasks,” etc.

What makes a good User Story? To answer this question, a look at the three Cs by Ron Jeffries can help. They describe the most important elements of a User Story:

The three Cs show which characteristics make up a good story. In addition, Bill Wake’s “INVEST” criteria are also an important source of orientation for creating high-quality User Stories:

In summary, User Stories are a format that helps to understand customer needs and implement them. The focus here is on the user and what added value can be offered to the user. We hope this post will help you understand the function and structure of User Stories. Maybe it will even help you with your own User Stories!