User stories are small work assignments that put on display what the customer wants and values. Keep reading below to find out how to create them and manage their flow across the work process.
The traditional approach to managing what teams deliver to customers is by creating individual work items or tasks which contain the technical details of the work at hand. While that’s perfectly fine, there is one important aspect that some teams miss – the actual value that they’re delivering. After all, customers care about working functionalities, not how teams built them.
That’s why, to ensure transparency and understanding of the value that will be delivered to the market, many Agile teams create their work items in the form of "user stories".
In the following paragraphs, we’ll explore what user stories are, how they benefit knowledge work management, and how you keep track of their execution in practice.
A user story in Agile project management is a small piece of work that represents some working functionality and describes what the end-user wants (their requirements). This Agile term was first coined in software development as part of the eXtreme Programming (XP) process and essentially represents a small part of a system that is usable. In a software context, for example, a user story can be the development of functionality to cancel your subscription to a digital product.
On most occasions, there are multiple user stories combined together which represent a large piece of work, known as an "epic". Therefore, teams aim to build an Agile work structure by breaking down epics into user stories, so they can iteratively complete them until the entire product or service is ready for market release.
The main benefit of user stories is hidden within the term’s name. While a "user" is self-explanatory, their "story" represents the business perspective of the functionality that teams will be building. In other words, instead of visualizing only the technical details of a work item, user stories aim to make the business value transparent.
The goal is to involve customers in the project management process and communicate with them the progress of their requests from a business standpoint, so they can better understand what the final product would look like. Based on that information, customers can then change their requirements and give teams timely feedback. In turn, this cooperation increases the likelihood of releasing a valuable product/service on the market.
Apart from that, some other advantages of user stories include:
User stories are the voice of your customers. They define the desired functionalities and the value they expect you to deliver on the market. It is communication with your customers that will ensure that you are fully aware of what their problems and wants are, and thus, write good user stories to meet these expectations.
Let’s examine some examples and guidelines for writing user stories.
Writing user stories usually happens in the format below:
"As a ….................. (description of the user) I need/want ….................. (description of the functionality), so that I can …................... (description of the benefit)."
A simple example would be the following:
"As a visitor on the eCommerce website, I want to be able to filter products based on reviews, so that I can see the most trustworthy ones first".
Now, keep in mind that there isn’t a single rule to write user stories. Having said that, don’t look at the above-mentioned format as the best way to structure them. Instead, try to grasp the concept, so when writing user stories, answer the following questions:
Even though user stories have their roots in the software industry, more and more non-IT teams have begun utilizing them over the past years on their Agile journey. Let’s have a look at some examples to bring clarity.
Writing user stories doesn’t end with defining personas, functionalities, and their benefits from them. Instead, there are more elements you need to keep in mind that form an effective user story. Let’s summarize them below.
Teams usually write initial user stories at the beginning of a project as part of an exercise known as a "story writing workshop". Keep in mind that the initial workshop takes into consideration only the known details of the project or initiative. After that, as work details keep emerging over the course of the project in Agile, the workshop keeps running continuously and new user stories are written in an "ad-hoc" manner whenever customer requirements change.
During the story writing sessions, teams discuss only the high-level details of the new stories. Once they get closer to execution, they continuously refine them and add more work details. In Kanban, for example, this can happen as part of a process called "Upstream Kanban". Scrum teams, on the other hand, hold backlog refinement meetings before the start of a new iteration.
As we mentioned above, there isn’t a single best way to write user stories. You should go ahead and experiment based on the specifics of your own process. Still, if you are looking for some directions, you can follow the "INVEST" checklist:
So far, we’ve discussed what user stories are and how to create them. However, that’s just one part of the story. To deliver actual working functionalities to your customers, you need to keep an eye on their execution.
In practice, you can do this with the help of Kanban boards which allow you to visualize the state of your user stories across the work process. While you can have backlogs to collect customer requirements and continuously refine your stories, you can also visualize the stages/steps of your actual workflow. This helps you understand how user stories are flowing through the process so you can alleviate bottlenecks and optimize the product/service delivery process.
Spotting bottleneck and optimizing flow on a Kanban board
Regardless of whether you're using continuous flow (Kanban) or sprints (Scrum), or even a hybrid approach, the Kanban boards allow you to visualize different types of user stories. You can do this with the help of swimlanes or multiple workflows if you wish to create a completely separate delivery flow for a certain user story type.
Swimlanes for different types of work on a Kanban board
With the Kanban method, for example, you can also put Lean/Agile metrics such as lead/cycle time, throughput, and WIP to practice. Integrating them within your user stories will help you analyze how long it takes you to deliver customer value as well as how often you can do that. Tracking that type of data allows you to convert your planning efforts from estimating to forecasting through tools such as the Monte Carlo simulations.
Monte Carlo Simulation
Instead of exact delivery dates, this allows you to communicate probabilities that have uncertainty built within them. As a result, you will be able to make your service delivery process more reliable so it can continuously meet changing market requirements.
There is no defined role for writing user stories. In Agile, everyone on the team is equally involved in the process of defining and discussing all details of user stories. It is collaborative work, and each team member can create them.
As described by Ron Jeffries, another of the creators of XP, each user story has 3 main components:
The user story life cycle in Agile typically follows the following steps:
User stories are work assignments that describe users’ requirements and the value they expect to receive.
Features, in the context of software development, are individual functionalities of software.
User stories are work assignments that describe users’ wants and the value they expect to receive.
Requirements are criteria that a software feature should meet. They are often in the form of acceptance criteria that are part of the user stories.
for outcome-driven enterprise agility.
Agile user stories represent a small functionality that aims to capture and visualize the value for the end customer. User stories can be a part of Agile epics and they can consist of multiple tasks/subtasks. All of that can be visualized and managed through interactive Kanban boards. When writing user stories, look to: