5x better user stories

User stories are requirements that are written from the perspective of a user. They serve to capture the needs of the user and to present requirements clearly and comprehensibly for all those involved. Ultimately, user stories are the one medium where you usually connect and coordinate the different trades in reality. On the one hand, there are the stakeholders with whom you develop the requirements, the UX experts and the development team, which then implements these requirements in the form of user stories.

As there is usually a lot of room for improvement when creating user stories, we have compiled the five biggest stumbling blocks for user stories for you - based on our experience.

#1: When the WHY is not clear

An all-time favorite. Sometimes neither the team nor the product manager knows why they are actually implementing the story. And there can be many different reasons for this.

There are organizations that are very top-down and where solutions are not developed in teams, but instructions are followed from above.

But the development team in particular is a rare resource in the company. Therefore, it should always be considered in advance why this should be built at all and what exactly the benefits are. Then it is also easier for the development team to understand why it makes sense to build one thing or another.

Simple questions can also help here in discussions with stakeholders, such as:

Why do you need this?

Do you have data to help us prioritize?

And that's why the question you should always ask yourself first is WHY. It has to be very clear. Not only does this increase motivation, you can save yourself a lot of frustration and unnecessary work by asking yourself the WHY.

#2 When the focus is not on the user's perspective

The basic idea behind a user story is that it is formulated from the user's perspective. A user story informally describes a desired software function from the user's perspective.

I as ... (WHO), want to... (WHAT) , so that... (WHY)

Especially at the beginning of PM careers, we often see that user stories tend to be written from a PM perspective. As a PM, I would like to have the following feature. This is the wrong approach. You have to put yourself in the user's shoes and really think about what the user wants and how a user story works. The sentence: I as ... would like this ... to achieve this goal is always a test. Have I really understood the WHY? Why does anyone want this at all and why do we need it?

You should also think carefully about WHO the user really is. Users are usually thought of too broadly: so become more granular and segment into different end customer personas: Customer Service Agent, Marketing Manager, Father, Mountain Bike Enthusiast...

#3: When only the happy path is seen

As a PM, especially at the beginning and this is one of the reasons why refinements with developers become very stressful, is that you only really think about the happy path. But that's not enough. You will always run into problems, edge cases, and so you should consider all eventualities before actually going into development. Examples of different scenarios and acceptance criteria can help to clarify the different perspectives and needs of end users.

If in doubt, your team will challenge you well, but it is at least not worth going into a refinement completely blank. Some edge cases or challenges make your entire concept or user story un-implementable.

Here are a few classics:

What errors can occur?

What should happen in the event of an error?

What do charge states look like?

What do empty states look like (no data there)?‍

#4: When communication within the team is lacking

Not the one person refines the user story. Refinements are the process of improving something by making small changes. And that only happens in a team.

This canbejust software developersor it can also be combined with UX specialists, for example. They sit down together and talk about the requirements, ask questions and exchange suggestions.

The user stories are ultimately fed with input from the development team. A user story is a basis for discussion and if it is not discussed with the team, there is a high probability that many questions will arise during implementation. These questions need to be clarified before the product goes into development. The structure of the user story, consisting of several parts, is crucial for clear communication and understanding of user requirements. This means that a good refinement is also a massive time saver in the long term.

#5: When the outcome is neglected

A frequent discussion in product management is: How do we deliver not only output, but also outcome? We have a small example for you to illustrate this.

Let's take the example of a pizza order and delivery. The order is the user story. Someone takes the order on the phone (you as PM), then passes it on to the pizza baker (development team). Then there may be one or two more queries, then the pizza is made, then it goes to the person who delivers and they hand over the pizza (in our case, this is the digital delivery). And that's it. The output is the pizza. What is actually left out is the crucial step afterwards. Namely: How did the customer like the pizza? In this case, the outcome should be a satisfied, happy customer.

A user story is a brief and informal description of a software requirement from the perspective of the end user in order to clearly capture their needs. Too little attention is paid to the outcome, especially in the digital sector. Too little thought is given before implementation to what data can be collected to make success measurable. How can we show that the product or service really has an impact? How do we measure in a month, in two months, depending on the duration, whether it was really successful?

The outcome has an enormous influence on the success of the product. The collection of data to measure success and its results will, at best, be very satisfying for your team and will also provide you as a product manager with a good basis of information for management.

All 5 at a glance

Explore the WHY and you are on the safe side. Then make sure that the user perspective is in the foreground. Also think about problems and don't just consider the happy path. There are always edge cases that occur. A user story is a basis for discussion. Good requirements are created in a team and by including all perspectives. That's why communication within the team is definitely a crucial success factor. This is the tricky bit, because it requires good planning and regular reflection. Measure the outcome, not just the output. Make it clear in your user story how you want to measure success and regularly check whether this success is actually occurring.

By definition, a user story is a brief description of a desired software function that is written from the user's perspective. This definition serves as the basis for understanding and creating effective user stories.

Paying attention to all these aspects will lead to a significant improvement in your user stories.

‍