User Stories in Scrum: The All-You-Need-to-Know Guide

The goal is clear: You want to develop a product that delivers a high added value to customers. You want to achieve a result with which team members and stakeholders are satisfied. But how do you do that? How can you meet all the requirements of a product in small, thorough steps? 

In agile, user stories have proven to be an efficient tool for this. They take you step by step from the first idea to a product ready for sale. I’ll show you what user stories are, how to create them and how you can benefit from them. Well then, what is a user story in agile?

The definition of user stories in agile describes the requirements for a product from the user’s point of view. In other words: User stories tell you what features and functions a product should have. This makes them a key tool for discussing and validating user needs and working on their implementation with a common understanding. 

User stories provide a universal language that team members, stakeholders and customers understand and speak. In practice, this means you can use user stories to develop an understanding of the product the customer wants, leaving little room for misunderstanding. 

Several user stories together form a use case. That is the simple differentiation between use case vs. user stories. User stories and use cases have their origin in agile software development.

User stories describe the requirements and wishes for a project result to be created from the perspective of the customer. For this purpose, agile user stories have this elementary structure - you can use it as a user story template:

WHO (role), wants WHAT goal / wish WHY (Added value)?

Let’s take a closer look at the individual components of user stories:

WHO (USER)

You fill the WHO placeholder with your customer or a typical representative of your target group. How detailed you describe the WHO in the agile user story depends on the user story itself and on the progress of the project. Therefore, be detailed enough to create a meaningful user story.

WHAT (FUNCTION)

Here you place the wishes of the user. You can ask yourself what the user expects or needs. If your product is still in an early development phase, you can formulate assumptions based on your experience as to what functions the user expects. If you already have a similar product on the market, you can also derive the desired functions from the feedback on this product.

WHY (ADDED VALUE)

Only the added value shows why a function is important to the user. The WHY, therefore, allows you to honestly reflect on how well you know a customer’s requirements. Because: It’s easy to include a requirement in a user story — for example, because the customer expresses the wish to do so. But only when you understand why the customer needs it do you have the context for implementing the requirement. Only then can you question whether the customer’s suggestion/wish efficiently satisfies their actual need — or whether there might be a more intelligent way. Let’s look at an example: 

The customer wants a rain cape for cycling. You could therefore now include the requirement “rain cape”. Or you could ask the customer why he needs a rain cape. Let’s say the customer answers “Because I don’t want to get wet”. 

This means that you don’t necessarily have to deliver a rain cape. You could also deliver a bicycle with an integrated roof. The crucial thing is that the customer’s need or problem is solved by it — namely, not getting wet. The better you understand the “why”, the better you can design your user story.

What is a user story in agile (user story example)?

You now know the individual components of agile user stories. An agile user story example might look like this (yes, user stories can look very simple!): 

As a CUSTOMER I want A SECURE PASSWORD***,*** SO THAT MY CUSTOMER DATA IS PROTECTED.

Here, the “CUSTOMER” is the user, “A SECURE PASSWORD ” the function and “SO THAT MY CUSTOMER DATA IS PROTECTED ” the added value. 

When you work with user stories in Scrum, you add so-called acceptance criteria to them. Acceptance criteria describe the business requirements that user stories must meet at the time of acceptance. In other words: Acceptance criteria are the requirements you need for a user story to create value. \n\n(By the way, just to be sure: some people search for “what is a user stories” in Google. Obviously, user stories is plural and it should say “what are user stories” in that case.)

The meaning of agile user stories in the backlog can be more differentiated. Because in backlogs, user stories can not only describe requirements but also represent a specific hierarchy type. Thereby, there are these 3 hierarchy types:

Epics: Epics are broadly defined functional areas of a product whose concrete scope may still be unclear.

Features: Features are specific performance characteristics within an Epic.

Stories: Stories are technical agile user stories and user stories within a feature.

You can implement these hierarchy types within a sprint. They create a concrete benefit for the user. 

In order to write helpful user stories in agile project management, detailed discussions with everyone involved are crucial. These should give you a thorough understanding of the target audience and the product to be created. You can then, for example, derive personas from this. 

In addition, the so-called INVEST criteria’ help you to create a convincing user story:

Independent: A user story should be independent of other user stories. This means that the implementation of a story must not presuppose that another story has been implemented beforehand. This has the advantage that you can freely prioritize user stories or remove them from the backlog at any time. 

Let’s take another look at the bicycle example. Let’s say you decided to install a small roof over the saddle of the bicycle instead of a rain cape, so that the customer doesn’t get wet anymore. So that would be a user story. But now you realize that in order to install a roof, you first have to develop a more stable saddle to which the roof can be attached. That would be a different user story. Both stories build on each other. This is exactly what you should avoid.

Of course, it is sometimes unavoidable that you have to do one user story before another. But as a general rule, avoid user stories for which you first have to implement 20 other user stories.

Negotiable: Writing user stories can sometimes take quite a while - but they shouldn’t be set in stone afterwards. That means: Product Owner , stakeholders and developers should always discuss and specify a user story together. 

Valuable: The result of user stories in agile project management must have added value for the customer.

Estimable: A convincing user story enables the development team to estimate how much effort it will take to implement it.

Small: A user story should be so “small” that it can be implemented in a sprint.

Testable: User stories in Scrum should be testable. This is the only way to check whether they can really be implemented in practice.

If you are not yet familiar with writing user stories in Agile, at first glance these might just look like additional work. However, user stories give teams an important context for their tasks and thus clarify the importance of each individual task.

Basically, this is how you benefit from user stories:

User focus: User stories are like a problem-oriented to-do list. Your team can use them to keep track of their tasks and know exactly how to meet user needs.

Holistic cooperation: User stories show everyone involved where they’re going at a glance. This way, everyone can pull together and keep deciding how to add extra value to users. 

Creative solutions: User stories in agile software development produce creative results . Because they get teams to think critically about the best solution for the final product.

Constant successes: Each user story is a small challenge. Teams can therefore celebrate a small success after each story. This motivates throughout the entire development process.

I hope the question “what is a user story in agile” was answered to your satisfaction! User stories are an important tool in the work of agile teams. They show you again and again in detail for whom you are developing what and why. This not only helps you to create a high-quality product tailored to the target group, but also to keep the team motivated throughout the entire process. 

To be successful at this macro level of agile working, your organization as a whole needs to think and function in an agile way. To help you and your organization do this, we’ve worked with renowned experts to design Project Scagile It shows you in various webinars how to approach an agile transformation the right way. The training is free of charge. Feel free to take a look!

If you are searching for fun retrospective ideas, check out our post on 54 Kickass Retrospective Ideas for Agile Teams (including the Mario Kart Retro & the Team Morale Health Check).

By the way, one of the best methods of sustainably developing the agile mindset of team members is to implement an agile health check. Our free team health check kit can help you ask the right questions - just click through.