Imagine you want to order a taxi with your smartphone. You are standing at an intersection, using the convenient app, and it shows you how many taxis are available near you. Unfortunately, ‘near’ is defined differently here than you might have expected, as all taxis within a 20 km radius are displayed. Now you can scroll endlessly to book the right taxi. You ask yourself, “Who on earth programmed this app?” and decide to call the taxi dispatch instead. To prevent such situations, agile development teams use User Stories.
[youtube url=”https://youtu.be/0MVCIsN1CqE” width=”960″ height=”400″ responsive=”yes” autoplay=”no” mute=”no”]
Focus on the Benefit
User Stories are short, simple descriptions of a feature (product function) from the perspective of the person who desires the new functionality. This is usually a user or customer. They are generally written by everyone involved in product development and are often recorded on index cards or sticky notes, stored in a shoebox, or arranged on walls or tables to facilitate planning and discussion. They typically follow this simple template:
As a < user role > I want to < achieve a goal >, so that < a reason for the goal >.
The purpose of User Stories is to fuel discussion about implementation effort and priorities. The emphasis should therefore always be on the important third part of the User Story pattern, which is the benefit of the feature. It is often worthwhile to reverse the User Story and put the benefit first:
In order to < achieve a goal > as a < user role > < I want to >.
One advantage of agile User Stories is that they can be written with varying degrees of detail. We can write a User Story to cover large amounts of functionality. These large User Stories are commonly known as Epics. Here is an example:
As a user, I want to book the nearest available taxi driver with my smartphone to reach my destination quickly.
How do User Stories become more concrete?
- By breaking down a User Story into several smaller User Stories.
- By adding “Acceptance Criteria”
Since an Epic is usually too large for an agile team to complete in one iteration, it is broken down into several smaller User Stories before being worked on. The Epic above could be split into dozens (or possibly hundreds), including these two:
As a taxi driver, I want to be able to turn my availability on and off so that I can manage my working hours and breaks.
As a taxi passenger, I want to be able to share my location so that the nearest available taxi is shown to me.
Furthermore, before an iteration, so-called acceptance criteria should be defined (usually by the Product Owner), which are checked at the end of a development cycle. In our taxi driver example, these could be:
Ensure that users agree to “share location.”
Ensure that the user’s location is only shared with taxi drivers within a 5-kilometer radius.
At a Glance
- User Stories, alongside Epics, serve as a communication bridge between customers, engineers, designers, and suppliers. For the team, they provide a basis for discussion on how to proceed.
- User Stories consist of a few sentences; they are short, concise, and understandable, yet specific and detailed from the customer’s perspective.
- A User Story answers three questions:
1. Who is requesting something? (Role)
2. What does the requester want? (Function)
3. Why is this important for the business case? (Benefit)
[mc4wp_form id=”8867″]
