Readers of our Journal know perfectly well what Scrum is. We discussed this subject in articles such as: "What is Scrum?," "Sprint Retrospective," and "5 Scrum Values."
So, it's time to talk about the role of the User Story in the Scrum framework.
And it plays a significant role.
Agile methodologies focus on the end user whose needs, experiences, competencies, capabilities, and habits should be considered during a digital product's design, deployment, development, and improvement.
Discovering and understanding these requirements is the essence of the agile approach.
To fulfill these needs and expectations is to guarantee the user, to some extent, desired experiences while using a digital product.
A User Story is a tool that allows you to look at a website or mobile application from the perspective of its future user.
A well-written User Story (and well-developed user personas) helps to offer future users and customers the desired added value.
It won't be an exaggeration to say that if User Stories didn't exist, they would have to be immediately invented and used because, in Agile, they're a crucial tool that is used to describe a given function from the perspective of its model user.
So, what are User Stories, and how can they be defined? What are their roles in the Scrum framework and the entire software/digital product development process?
Are User Stories necessary? What are the benefits of User Stories? How to write a User Story?
In this article, we'll answer these fundamental questions and provide some user story examples.
We cordially invite you to read it!
Are you looking for a Web Development Company?
User Story in Scrum or what are User Stories?
User Stories should be associated with Agile methodologies, especially with its most popular agile framework — Scrum.
A User Story primarily lets you determine what the user wants and why they want it.
A User Story is a form of expressing a functional requirement concisely and simply without technical details, and most importantly, it should be expressed from the user's perspective.
Instead of using descriptions, sets of traits, or terms regarding a particular function, User Stories refer to the simple expression of goals, needs, and sometimes ways of achieving and fulfilling them.
In short, you tell a User Story, not talk about it. This difference may seem too subtle or purely linguistic, but it does have an entirely different meaning in practice.
By telling a User Story, it is much easier to communicate expectations, and it's easier to understand by various stakeholders.
User Stories are useful for a design or development team and other people involved in the project.
The term User Story is nothing new. It was created in 1997, and it became more popular along with the release of the book written by the author of this term Kent Beck, "Extreme Programming Explained," in 1999.
According to the first meaning of this term, User Story is about product attributes described from the user's/customer's perspective.
The uniqueness of User Stories stems from a special perspective through which expectations are communicated. It's not only about what a system should offer, have but what it can do for the user.
The whole weight is shifted from a product to its user.
Let's refer to a more illustrative example. Radio isn't useful because it receives radio waves but because it allows the user to listen to their favorite broadcast.
Radio that enables you to "catch a given station" on which a broadcast is aired offers a particular value that the user expects.
Radio that doesn't pick up any frequency guaranteeing access to a radio broadcast is seen as a device that contributes nothing to the listener's daily life.
The situation doesn't look different regarding functionalities offered on websites or web applications.
Simply offering them doesn't bring value. The value appears along with fitting in with a given user group's needs, expectations, experiences, habits, and capabilities.
In Agile, User Stories help realize this goal.
In the Agile methodology, in the Scrum framework, User Stories are simply short, one- or two-sentenced, informal, simple descriptions of what the end user wants to do or achieve with the software.
It's the description of the goal they want to achieve, the value that is important and valuable to them, and the benefit that they want to have.
User Stories allow you to determine what features and functions a product should have. User Stories are a very important tool for defining users' needs.
While talking about what users would wish for, they talk about their needs and expectations regarding a digital product.
They form their perceptions about how it works and the goals they want to achieve as illustratively and precisely as possible.
The code of a future web or mobile application, created based on a User Story, should answer these needs, expectations, and goals in terms of functions and usability.
At the same time, User Stories enable you to give these needs a universally understood form — or at least it should be like that — and easy and quick to communicate.
In Scrum, a User Story also represents the smallest unit of work that should be done within a given project.
Let's emphasize it one more time: in an informal way, a User Story describes the function of the software, web application, or mobile app in a natural language used by the end user.
Using natural language instead of, for example, IT jargon also has another advantage. It makes User Stories more understandable for scrum team members, other stakeholders, and customers of a web development company or UX agency.
User Stories are often grouped into sets that, in Agile, Scrum, are called Use Cases, and their purpose is to answer the question of "What will users do with the software?."
Use Cases describe entire sequences of interactions that occur between a system (web or mobile app) and the user.
Use Cases illustrate how users achieve goals.
Let's refer to another example.
A Use Case may be the way of creating a customer account in an online store.
The interactions needed to create it usually include entering data into forms, creating a password, verifying an e-mail address, and entering a credit card number.
And all these activities are often split into stages. All these actions can be expressed through multiple User Stories that, when combined, will create a logical and consistent Use Case.
However, the above findings require adding a significant observation made by Yvette Francino in the article "User Story."
As Francino rightly observes, User Stories shouldn't be treated as substitutes for Use Cases and even more so as substitutes for documentation of functional requirements.
User Stories should be used as tools to prioritize adding functionalities within subsequent Sprints.
A User Story may also be used as a starting point for determining the set of requirements that a digital product should meet.
That was the first meaning of User Stories. Initially, they were written on sticky notes and stuck to a publicly available board.
Thanks to that, every Agile team member had access to them and could freely plan work with their help.
Currently, User Stories often take a digital form. They're written in dedicated tools (e.g., Jira) as an element of a Product Backlog to which they go after Sprint planning.
So, who writes User Stories? Is this task assigned to a specific role or specialization within the scrum team?
As a rule, no single person is assigned to this task in the Scrum framework. Anyone can write User Stories.
It's a best practice to do this task as a team and create them based on the accumulated knowledge and experiences of the entire scrum team and stakeholders.
Types of User Stories
User Stories can also be divided into types, depending on what they're describing.
According to the article "Agile User Story Example and Templates," there are two main types of User Stories.
Functional User Stories
As the name suggests, they focus on the functions and features of a digital product. They concentrate on the user and the value these functionalities bring them.
Technical User Stories
They support Functional User Stories and can be divided further into Infrastructure Stories, Refactoring, and Spikes.
Infrastructure Stories
They describe any infrastructure additions necessary for a Functional Story.
Refactoring
This type of User Story focuses on describing technical debts and issues regarding code maintenance. It can support automation and design activities.
Spikes
Spikes concentrate on researching architecture and design. These User Stories help the team gather more information on, among others, how long it will take to complete a given story.
Form of a User Story or how to write a good User Story?
User Stories are written in natural language, and to complete their tasks, they can't be a collection of random sentences.
In other words, User Stories should be written according to the adopted form and pattern, the so-called user story template.
An appropriate structure will enable you to capture the essence and reduce the risk that the User Story will be ambiguous, uncommunicative, unspecific, and hence moderately useful or completely useless.
Sticking to the structure also allows you to easily capture the sense of the task and make it more useful for the scrum team — both design and development teams.
A User Story often takes the form of three elements that are answers to the following questions:
- As a Person/Role (Who?)
- I need/want (What?)
- To/because (Why?)
An agile user story example can look like this: As a customer of an online store, I want to be able to create an account so that I don't have to reenter contact details when repeating a purchase.
A User Story can also be expressed with a pattern in which you determine the role, feature, and benefit:
- As a (User Persona, Role)
- I want (Determination of how the function works)
- To (Indication of the benefit and/or value)
For instance: As a logged-in user, I want the store to automatically complete my contact details during subsequent purchases so I can save time.
If you would like to see more user story examples or, rather, user story templates, then click here.
When indicating a Persona or Role who wants to use a given function, make sure it matches the description of the Persona that represents a given segment of the target group to be as faithful a reflection as possible of who the real customer and/or user is.
The perception of the user should be as realistic as possible. They can't be some kind of abstract being who simply uses the functions of a system.
User Stories are meant to express actual needs and benefits, and it's worth keeping in mind that their justification isn't always logical, consistent, and obvious.
When writing a User Story, you need to know what specific traits and characteristics a given user has. What determines them, encourages them, interests them, and what they see as attractive and useful.
For example, by knowing how old they are, where they live, what gender they are, what their interests are, what job they do, and what experiences and digital competencies they have, you know what they can expect from a system (even if it's still pretty general).
The more specific the perception of the model user, the more accurate will be the needs we want to fulfill and which are expressed in the middle part of a User Story that answers the question of "What?".
Determining benefits, values, and/or understating why a particular function is important and necessary for the user causes the most problems for the creators of User Stories.
Because needs can be fulfilled in many ways, or a particular function in a web or mobile app can fulfill and often does a few needs simultaneously.
Finding the one the user is looking for the most is a task that requires a considerable amount of knowledge about the target group (also obtained through usability testing) and certain experience and empathy.
While writing User Stories, you should remember that they can be created at various levels of detail.
As a rule, the more general the User Story, the more detailed stories it contains that create a consistent whole called an Epic.
An Epic, a collection of related User Stories, usually can't be deployed within a single Sprint; that's why a best practice is to divide them into smaller User Stories.
While creating a User Story, it's essential to consider the following:
- The Definition of Done
- Main and additional tasks
- All Personas and Roles — in particular, you should check whether a given Story is relevant for everyone, which is not impossible but also not obvious
- Real expectations, needs, and motivations of users/customers that can be discovered with UX research
- The level of complexity of a User Story that determines the time needed for its implementation within a single Sprint.
We wrote in more detail about the ways and techniques for validating, evaluating, and accepting User Stories in the article "User Story acceptance criteria."
We want to add, as a reminder, that acceptance criteria allow you to determine whether a given User Story meets various expectations, including business ones.
Let's refer to our example with the User Story about registering. One of the acceptance criteria should be determining what data are expected to be entered, what ways of validation, and what hints and alerts should be offered to the user.
Fundamental purposes of creating User Stories in Scrum
User Stories in the Scrum framework are fundamental to tasks performed within a given Sprint.
As we've written above, User Stories are the smallest unit of work, thanks to which they're also a reference point for planning work.
Both in regard to its duration, order as well as dependencies between them.
The more experience with User Stories Scrum teams have, the more precisely they can estimate the time of work, plan Sprints, and predict the course of a project.
User Stories are also appreciated for:
- Promoting and improving cooperation between scrum team members
- Focusing attention on tasks and simultaneously on users standing behind them, whose problems and needs are represented by a User Story, which allows you to resolve and fulfill them
- Supporting critical, creative, out-of-the-box thinking
- Their mobilizing and awarding character — finishing a Story positively influences the motivation to work, seeing its purpose and meaning.
Christiaan Verwijs, in the article "The purpose of User Stories in Scrum," indicated in a very exhaustive way other benefits for scrum teams that use User Stories.
A User Story, according to Verwijs, is also used to:
- Improve and optimize functionalities in terms of their operation, effects, and goals
- Obtain a bigger picture thanks to which teams can see what an app will be able to do or won't be able to do for users
- Prioritize tasks
- Communicate key features of functionality in a short, communicative, straightforward manner, which in a sense, counteracts the paralyzing practices of creating an actual specification — User Stories can't be treated as substitutes for a specification.
Why else should you create User Stories in Scrum?
Because they represent a unit of work that can be simultaneously created and added to the Product Backlog at any moment and can be done at any time the scrum team deems optimal.
Let us remind you that within the Scrum framework, Product Backlog is a list of functions meant to be developed in the digital product.
User Stories have become an optimal and very popular form of establishing elements of the product registry.
The ability to plan Sprints, to incorporate a given User Story into a Sprint allows you to lead the project in a more flexible way that is tailored to changing needs.
Stories also enable you to estimate the complexity of work and the time needed to perform it.
Estimating the working time required for an item in the Product Backlog is often done using various techniques (e.g., Fibonacci sequence).
In other words, User Stories in the Scum framework allow you to better control the course of the project, manage tasks, give them ranks, estimate work, and motivate team members.
You also can't forget that Agile and Scrum are based on specific values, and User Stories manifest that.
Agile prioritizes people/users and their interactions; hence a User Story helps you see the purely human dimension of interactions, human needs, and functions behind them.
The scrum team also uses the human-oriented approach. By reading a User Story written in a natural language, the team can understand the context, benefits, and needs better.
User Stories not only allow you to offer end users tools and technological solutions but also a specific value, that, admittedly, comes from "technicalities" but doesn't boil down to it.
User Story in Scrum. Summary
- Agile methodologies focus on the needs of the end user.
- The end user's expectations, experiences, competencies, capabilities, and habits should be considered when designing, deploying, developing, and improving the digital product.
- A User Story primarily lets you determine what the user wants and why they want it.
- The uniqueness of User Stories stems from a special perspective through which expectations are communicated.
- It's not only about what a system should offer, have but what it can do for the user.
- In Agile software development, in the Scrum framework, User Stories are simply short, one- or two-sentenced, informal, simple descriptions of what the end user wants to do or achieve with the software.
- A User Story describes the goal they want to achieve, the value that is important and valuable to them, and the benefit they want.
- There are two main types of User Stories: Functional User Stories and Technical User Stories.
- In Scrum, a User Story also represents the smallest unit of work that should be done within a given project.
- A User Story should be written according to the adopted format and pattern.
- User Stories in the Scrum framework are a certain requirement, a fundament to tasks performed within a given Sprint.
- Agile prioritizes people/users and their interactions; hence a User Story helps you see the purely human dimension of interactions, human needs, and functions behind them.
