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?
What is a user story in agile? Use case vs. user stories
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.
How are agile user stories structured (user story template)?
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)
This is maybe the most important part of the user story template. 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. After all, including a requirement in a user story is easy - for example, because the customer expresses a desire for it. But only when you understand why the customer needs it, you do have the context for implementing the requirement. Only then you can question whether the customer's suggestion/request efficiently satisfies their actual need - or whether there might be a smarter way. Let's take a look at a user story example for this:
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".
That means you don't necessarily have to provide a rain cape. You could also supply a bike with an integrated roof. The important thing is that the customer's need or problem is solved with the user story – namely, not to get wet. The better you understand the “why”, the better you can design your user story.
Most Agile Coaches and Scrum Masters run in circles...
...fixing superficial symptoms. Time to use psychology to foster sustainable mindset change.
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.
What is a user stories in Scrum?
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. (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.
Writing user stories – How do I create convincing user stories?
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. That means: The implementation of a story must not require that another story has been implemented beforehand. This has the advantage that you can freely prioritize user stories at any time or remove them from the backlog.
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 a long time - which does not mean they are set in stone afterwards. Accordingly, 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.
This is how you benefit from user stories in agile
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.
Conclusion
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).
