User Stories: How to Ensure Value Delivery in Agile?

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.  

User Stories in Agile: Definition and Main Benefits

A user story in Agile project management is a small piece of work that represents some kind of working functionality and describes what the end-user wants (their requirements). The 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.

But 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. For example, in mechanical engineering, a user story could be the creation of a safety mechanism that you install on a physical product. In a marketing context - a promotional video for a customer campaign, so on and so forth.

On most occasions, there are multiple user stories combined together which represent a large piece of work, known as an “epic”. Therefore, Agile teams aim to break down epics into user stories, so they can iteratively complete them until the entire product or service is ready for market release. 

Why Are User Stories Effective?

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: 

• Improved team collaboration – User stories help teams lead more productive conversations about how to deliver the best possible product/service as they are solely focused on capturing the customer’s intent
• Shared understanding – With the help of user stories, development teams can create a shared understanding among all stakeholders about their work, so everybody stays on the same page.
• Work prioritization based on business value – User stories help teams understand the most valuable customer requests so they can deliver them as fast as possible.

Writing User Stories for Maximum Business Value

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:

• What is the user persona to which the story is addressed? For example, the user could be a regular engineer or a CTO. That’s mostly based on your product’s overall targeting profile, but keep in mind that for different functionalities, you might have different personas. Defining the user persona is important because it helps teams better understand what they need to do to satisfy the customer’s requirements.
• What functionality does the user need? This entails the actual work that will be executed as part of the user story from the customer’s perspective.
• Why does the user need that functionality? This is the part that differentiates user stories from normal tasks or work items. It’s important to define the benefit/value that the functionality delivers and communicate it with your customers. This allows you to keep them in the loop and ensure that you are on the right track to creating value with your product or service.

What to Keep in Mind When Creating User Stories?

Writing user stories doesn’t end with defining personas, functionalities, and the 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.

• Definition of Done – it’s important to define what “done” means in your process. This can be in the form of certain policies that specify what the final result should “look like”. 
• Acceptance Criteria – While the “definition of done” usually applies to the whole process or separate workflows, each user story might have unique acceptance criteria. Usually, those criteria are in the form of checklists that need to be met before the story is considered complete. Agile teams also execute regular acceptance tests or reviews to ensure the story can be “accepted” by the customer.
• Tasks/Subtasks - Even though user stories are often considered the smallest unit of work in an Agile environment, it’s important to know that they can contain tasks or subtasks. While the story communicates the value of the work at hand from the customer’s perspective, its corresponding tasks/subtasks represent the technical details.
• Size – It’s a popular Agile practice to size the user stories appropriately, so teams have an idea of how complex the work is. This is usually done by using “T-shirt” sizes and the approach relies on grouping all user stories based on their complexity. 

When to Write User Stories?

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.

The “INVEST” Approach to Writing User Stories

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:

• Independent - This refers to eliminating the dependencies between user stories, so each story can be completed on its own. However, while that’s an ideal situation, keep in mind it’s not always possible in the real world. That’s why, if you can’t make a story completely independent, look to visualize its dependencies with other work items so you can better understand their flow.
• Negotiable – Every user story should be “open to conversation”. In other words, try to write them in a way that promotes collaboration between the customer and the team. Remember that the goal is to provide value to the customer, instead of building something for the sake of increasing your output.
• Valuable – This is an extension of the previous point. If the story doesn’t provide value, then you shouldn’t build it.
• Estimable – It's a good practice to have an idea of how complex the story is. If the difficulty is too high, then you’re probably dealing with an “epic” which you should break down into smaller user stories. However, keep in mind that in a Lean/Agile method such as Kanban, this type of estimation becomes redundant. That’s because teams rely on historical cycle time data to determine the “size” of their user stories.
• Small – You should look to reduce the batch size of a user story as much as possible. The idea is to create a smoother flow throughout your work process.  
• Testable – Every user story in the process should have clear acceptance criteria so teams can execute acceptance tests and ensure the story delivers value to the customer.

Managing the Flow of User Stories

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.

Try Kanbanize for free

In Summary

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:

• Define the customer persona 
• Specify their requirement 
• Make the benefit clear 
• Include acceptance criteria and run acceptance tests