User stories are part of an agile approach that helps shift the focus from writing about requirements to talking about them. All agile user stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality.
What is a User Story? The definition
The User Story represents an Agile practice, especially used in Scrum, that “captures” the needs of users.
It does this by expressing characteristics, functions and requirements for the product to be made in a general and non-detailed way.
The User Story is part of the Product Backlog. In Scrum, the Product Backlog includes a “list” of all the things that need to be integrated into the project. The User Story looks simple but is truly effective.
It requires to focus on the needs and needs of the user (and/or customer) and on the value to be achieved.
The user’s history is often written on cardboard or post-it and is attached to the wall or on tables in order to facilitate planning and discussion. In this way, the User Story manages to control the attention from the writing of the functionalities to the comparison regarding the functionalities. The User Story demonstrates the importance of the affirmation of the Agile Manifesto “the software working rather than the exhaustive documentation“.
What is a User Story used for?
User Stories are a great way to clearly define what a user wants from a product/service.
A set of well written and prioritized user stories can certainly help the team to express and share the product features without going into technical details.
A user story allows you to understand the importance and impact of a feature on the business. It also helps to make the customer understand the usefulness of the feature and its priority.
If well written, a user story provides a solid basis for communication and collaboration, bringing the user to the centre of attention. The Use of User Stories facilitates discussions on the product, both within the development team and with external stakeholders.
What is the User Story made of?
Each User Story describes why & what to do in a simple, understandable way for the customer and developers.
The point of view is that of the user, who requires the new functionality. The amount of information is that which is essential to allow the development team to make a rough estimate of the work required for the realization.
There are several ways of writing a user story. Usually, the User Story contains a name, a brief description and the specific acceptance criteria and conditions for which the story can be considered complete.
A model can be:
As a <type of user>, I want <some goal> so that <some reason>.
Here are two examples:
- As a customer, I want to cancel my hotel reservation in order to get a refund
- As an online customer, I want to be able to log in to access my account securely.
The User Story makes dialogue with the customer and/or user necessary because it is thanks to the dialogue that we are able to understand all the various aspects of the story. Because of the User Story, we can have a good understanding of what and why we have to develop that specific functionality.
Fundamental characteristics of the User Story
User stories should always contain 6 characteristics, represented by the acronym INVEST, created by Bill Wake *:
Independent: they must be independent of each other.
Negotiable: they must be “negotiable” and open to everyone’s contributions.
Valuable: they must bring added value to the customer.
Estimable: they must be estimable, not exactly, but enough to allow rough planning for implementation.
Small: they must be small, in order to be able to realize the functionality in a couple of weeks of work. They must be small because in this way the estimates are more precise. If the story is too complex, I break it down into multiple stories.
Testable: they must be able to be tested and must-have information on how to carry out the tests.
See here an example of how to break down a user story into simpler user stories.
Who writes the user story?
User stories can be written by anyone with the skills necessary to write them. Most often they are written by the Product Owner. But they can also be written in collaboration with the entire team.
Acceptance criteria
Together with user stories, it is important to develop acceptance criteria, that is, criteria that must be used to evaluate whether a story has been correctly and fully implemented. These criteria are the conditions that the software product must comply with in order to be accepted by the user and / or customer.
Acceptance criteria are essential to understand when the goal of the user story is achieved.
Format
The user story is often written on an A6 paper. The small format obliges you not to use too much information.
The card is useful because it is easy to use and makes it possible to group the cards on the wall or on the table. Grouping them makes it easier to evaluate the consistency, completeness and connections between different stories. Even if you have electronic stories, it can be helpful to use cardstock.
Another important factor is visibility: the stories must be visible to the whole team.
Basically they represent the unit of work that the team is committed to achieving in a sprint.
What are the key features of an agile sprint? Read the blog post the 5 characteristics of a successful agile sprint!
*INVEST in Good Stories, and SMART Tasks
Copyright © 2019 Agile Business Consortium all rights reserved
Skip to content
