Scrum Guide | 19. User Stories - what they are?

User Story is a brief description of a new Product functionality or its enhancement. It does not contain a technical solution but addresses questions concerning the functionality: Who is the user? What does the Product do? And What is its purpose? The User Story describes the product in everyday or business language, though it also points to Scrum Team’s tasks that are intended to improve the Team’s performance.

What are User Stories? – table of contents:

Introduction
User Story. Whose story is it?
How to use User Stories?
Acceptance Criteria
Summary

Introduction

User Story is the most common way of formulating the tasks performed by the Scrum Team. A single User Story defines a small functionality of the Product. It describes the smallest meaningful, partial Product Goal. For this reason, User Stories are very brief.

User Stories are created throughout the entire time of working on the Product. They are created continuously, from the moment the decision to start work is made, to the realization of the Product Goal.

Creating User Stories is a Product Owner’s task. Based on a conversation with a Customer, formulates answers to questions that allow to create User Story and enters them into the Product Backlog. However, User Stories reflect not only customer needs.

User Story. Whose story is it?

The Scrum Team creates a User Story to define the User’s needs, and that’s why it is put down in business language. In other words, it indicates the benefits that its implementation will bring to the product user. However, in the Product Backlog, there can also be User Stories that describe the needs of the Development Team, for example improving the workflow between Developers, or describing the needs of the Product Owner, for example organizing the Product Backlog. In such cases, the User in the User Story is the Developer and the Product Owner.

You can describe a User Story by answering the 3W questions:

Who?
Is doing What?
Why?

The User Story is then contained in a formula:

As a [user type], I want [to do what?] Because [why? why?].

Examples of User Stories about the functionality of an online store written in this form are illustrated in the table below:

This formula allows not only to formulate a User Story but also to relatively easily translate technical language into business and vice versa. As a result, both Developers and Stakeholders see clearly the Goal and stages of its progress. We will also cover creating good User Stories using the INVEST method in a separate article in the Scrum Guide series.

How to use User Stories?

Creating a schematic User Story is just the beginning. They are signals and starting points for discussions on problems and their solutions. Discussing User Stories takes place during Sprint Planning to sort out which technical issues the Development team will add to the Sprint Backlog.

Typically, in the physical space, User Stories are written on small, colored cardspinned in the workplace. However, in the digital space, digital whiteboards, shared by the Scrum Team, work best.

Saving User Stories in this way has several advantages because:

Stresses the autonomy of each User Story – each has a separate framework and can be executed independently of the others
Emphasizes the dynamics of User Stories – the order of their realization is renegotiated by the Scrum Team and the current order of realization is visible on the board thanks to the physical arrangement of cards with User Stories
Serves as a reminder – thanks to the visual representation of User Stories, the Scrum Team has a signpost in sight to remind them of the goal when creating detailed solutions.

The Development Team estimates the required effort to complete a User Story with days, man-hours, or Story Points.

Acceptance Criteria

A User Story must have certain acceptance criteria at the very moment it is accepted for development by the Development Team. The acceptance criteria determine at what point work on a User Story can be considered finished.

This way both the client and the developers know how their work will translate into business value. Typically, a User Story is considered completed when the user-specified in it can perform the action described. Using the example above, take a look at this User Story with the content:

A customer can buy a magic wand with a single click.

It is completed when a working ”Buy Now” button appears on the online store page, which uses the default payment and shipping information for the logged-in user.

Summary

A User Story is a concise description of a new Product functionality or enhancement. It serves as the smallest Goal expressed in business language, that is, from the perspective of the business value and the user. It helps to clearly define the task to be performed as well as the criteria for its completion.

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