You have probably heard the term “User Story” already—especially if you have already been involved in agile projects. If you still have little experience in agile project management, then this article is just right for you. Here I explain in detail what User Stories are and how they are created and documented. Read on and learn more!
The Scrum Guide Does Not Know User Stories
In the Scrum Guide you will not find the term User Story or requirement. The Scrum Guide 2020 has replaced the term requirement, somewhat unfortunate, by the neural term “Product Backlog Item” (PBI). However, it has proven useful in Scrum practice to describe desired functionality (i.e. requirements) in the form of a User Story.
A User Story is a software requirement written in everyday language from the user’s point of view. It defines a Value for the user or buyer of the product. A User Story is deliberately kept short and usually comprises no more than two sentences written on the front of an index card.
User Stories describe requirements from the user’s perspective.”
The difference with requirements is, requirements define more specific details, while User Stories leave more room open for discussion. These discussions are then held in Sprint Planning. The requirements are actually “hidden” in the User Stories. You deliberately leave open how the User Stories will be implemented exactly.
User Stories are written in a specific form with three variables:
- Role (Who?)
- Goal/Wish (What? Functional description, action)
- Benefit/Reason (Why?)
As <Role> I want <Goal/Wish>, to achieve <Benefit/Reason>
Example: As <data editor> I want <to see my last edited document>, to <save time>
Role – Most software systems have different users working with them. This can be a clerk who enters data, an administrator who configures the system, or a salesperson who processes orders. Very often, software systems have a role and rights system that distinguishes certain roles and defines access rights to data. This is another reason why it is important for you to know which role something performs.
Goal/Wish – This is the functional description, the action that the role performs. The description does not have to be detailed. You should also avoid describing solution approaches. So describe only WHAT is to be done and not HOW it should be done.
Benefit/Reason – This important part of the User Story is often forgotten or simply not described. This is because it is not always so easy to define the benefit. “Why questions” help here. The benefit is an essential element when it comes to discussing possible solutions later on.
There is often additional information written on the User Story card. This includes:
- An identification number (useful if the User Story is stored in software).
- References (e.g., who brought in the requirement)
- An effort estimate (in story points)
- Acceptance criteria
Examples of User Stories
One of the advantages of agile User Stories is that they can be written at varying levels of detail. You can write a User Story to cover large amounts of functionality. These large User Stories are called Epics. Here is an example of a large User Story from a desktop backup product:
- As a User, I can back up my entire hard drive.
Since an Epic is often too large for an agile team to complete in one iteration, it is broken down into several smaller User Stories before being worked on. You could split the Epic above into several User Stories, including these two:
- As a power user, I can specify files or folders to back up based on file size, creation date, and modification date.
- As a user, I can specify folders not to back up, so my backup drive doesn’t get filled with things I don’t need to back up.
User Stories on Index Cards for Discussion
User Stories are preferably written on index or pin board cards and posted for everyone to see so they can be discussed. Yes, this can be cumbersome or seem old-fashioned to you. But this has its special benefit, because the “notes” are so always present for everyone. One of the principles of Scrum is mutual exchange (communication) and good visibility—and index cards are ideal for this.
If you use software to manage the backlog and store all User Stories there, you have everything nicely managed and safe from the cleaning lady, but this has the disadvantage that little or nothing is discussed about the User Stories. Or have you ever seen four developers discussing a User Story in front of a screen?
However, this does not mean that User Stories cannot also (additionally) be captured electronically in software. This has an advantage, for example, with distributed teams or when all team members are in the home office because of a pandemic.
User Stories are part of the agile approach, that shifts the focus from writing about requirements to talking about those requirements.”
The following figure shows the front of an index card on which a User Story is written. On the back, it has space for further information, such as acceptance criteria or dependencies on other stories or risks.
User Stories According to the 3C Criteria
In addition to the good characteristics of User Stories by Bill Wake (INVEST), the “3C Criteria” by Ron Jeffries are also often used. These have the following meaning:
Cards (Story Cards) – Already when the agile movement started, User Stories were preferably written on cards (or post-it’s). This has not changed until now. The idea behind it is: You can’t write much on a small card—there is no room for details or specifications on it.
Conversation – The description on the story card is intentionally kept short so that it has to be discussed. Conversation between Developers, Product Owner and customer is essential to clarify details and remove ambiguities.
Confirmation – The User Story must be verifiable and testable. The acceptance criteria are often written on the back of the story card for practical reasons.
Who Writes User Stories and When?
Anyone can write User Stories. However, the Product Owner is responsible for ensuring that a Product Backlog with User Stories exists. This does not mean that the Product Owner is the one who writes them—this can be the team members but also stakeholders. It matters less who writes a user story than who is involved in the discussions about it.
User Stories are written throughout the life of the project. Usually, at the beginning of an agile project, a workshop is held where initial User Stories are written. Everyone on the team participates, with the goal of creating a product backlog that describes functionality for at least the next two to three releases.
User Stories Should Be Small
If some User Stories are too big for the next two sprints, e.g. bigger than “8”, then the Scrum team should try to split them up further. For bigger stories that will be implemented later, this work is not worth it. Because these may look completely different in a few weeks or will never be implemented. These stories can also be bigger.
Why is it important to split up big User Stories? The short answer is: to fit them into one sprint. But that’s only half the truth. I’ll show you two other important reasons why:
- “The power of small wins”: The more often teams experience a sense of progress, even if it’s in small increments, the more likely the team will be creative, productive, and motivated in the long run (Amabile, 2011).
- Splitting stories into smaller ones is also important to avoid the 90% syndrome. Tom Cargill of Bell Labs expressed this in 1985 for software development with the “ninety-ninety rule” as follows:
The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.”
Tom Cargill, Bell Labs
This effect is typically caused by the acquired knowledge of the solution path and the ignorance of the still occurring disturbances and problems. Splitting User Stories is not always easy—but make the effort!
Here You Can Find Even More Knowledge
Would you like to learn more about how to make your projects more successful with Scrum and Agile Project Management? My book Scrum – How to Successfully Apply Agile Project Management and Scrum takes you an important step further!
Do you know somebody who might be interested in this article? Then forward it or share it. Thank you!
