Seven techniques to improve user stories

One of the hardest things to do as either a Product Owner or as a team, is to create proper user stories. Creating well-formulated user stories, backed up with the Definition of Done, acceptance criteria and maybe dependencies on other user stories/people/missing knowledge, leaves little to no room for assumptions. This has the advantage that the collective idea of that what has to be created is the same, preventing any unwanted surprise upon delivery.
#

Seven techniques to improve user stories

One of the hardest things to do as either a Product Owner or as a team, is to create proper user stories. Creating well-formulated user stories, backed up with the Definition of Done, acceptance criteria and maybe dependencies on other user stories/people/missing knowledge, leaves little to no room for assumptions. This has the advantage that the collective idea of that what has to be created is the same, preventing any unwanted surprise upon delivery.

This seems like a pretty logical statement, doesn’t it? Is not that logical in practice. In fact, it can be pretty hard. It can be hard for the customer to know exactly what he wants, let alone you trying to mold that into a simple hypothesis. Here a few tips to get you started:

#1: Focus on the user

Focusing on the user instantly let’s you see for who you are creating the work. Write down the exact role of the user. Just ‘user’ can be really generic. If you’re creating a large piece of software, and multiple departments are going to use it, dive down into the exact role of the user. Let’s say we are creating new functionalities for a piece of software for a hotel. The ‘who’ can be defined as follows: “As a front-desk employee…”. If the Product Owner needs to retrieve extra detailing on, for instance, acceptance criteria, it’s easier to find the target audience, than when the user story only says “As a user…”.

#2: Focus on the ‘what’

Now we know the exact user, we can note down what we are going to create. This is a specific feature, or action, the user can control/use. Let’s continue on the front-desk employee story: “As a front-desk employee, I want to be able to book rooms manually”. Now we know what we’re going to build, but we still don’t know why we want to do so. Yes, because it’s our job to build stuff. But we don’t know what the goal, what the intent, of the feature is.

#3: Focus on the intent

The intent is the benefit that is gained from the feature that is being created. Why does the front-desk employee want this feature? Is there a problem he wants to solve, or is it something he doesn’t really need but wants to have? Having the goal clear in mind, we can think of ways to achieve the goal and the PO can decide on the priority. Now the entire user story is complete: “As a front-desk employee, I want to be able to book rooms manually, so we are not solely reliant on the internet”.

#4: Involve the stakeholders/end users

And I mean really involve them. They’re the ones that will be working with the product of the team, so they can provide you with the best insights, the feeling that they want to have with the product.
Do they always get exactly what they want? Absolutely not. But you can help them determine what needs to be done first. Making it clear that their opinion really matters and that their input is a major success factor for the end result, will also make them feel they really matter in the development process.

The flip side is that if you don’t involve them, the team will have to start creating their own idea of what they think value for the customer is. And that will, of course, lead to discrepancy in the expectations.

#5: Keep asking why five times

Proceed to keep asking the why question as many as five times. That many? Yes, because that will bring up the root cause of the problem that is at hand. Developed, like a few other well-known techniques, at the Toyota Motor Corporation by Sakichi Toyoda, to become better at delivering the best product available on the market.

“As a front-desk employee, I want to be able to book rooms manually, so we are not solely reliant on the internet”

Why?: So I can book a room for a customer even when the internet is down.
Why?: So that the client can stay at our hotel, even though they didn’t book in advance.
Why?: So we can provide a broad range of service for the customer.
Why?: Because we want to be the best hotel in the country.
Why?: Because this helps us get bigger clientele and thus make more money.

So the ultimate goal is to support creating the revenue. The strategic advantage the solution creates, is supportive of the root cause. Knowing the exact root cause helps you figure out what the client really wants and needs.

#6: Refine the user stories with only the relevant people

Having a large group of stakeholders/key users plus team present will result in endless discussion. Jeff Bezos keeps meetings easy and efficient by keeping the size to a ‘two pizza’ size. If two large pizza’s are big enough to feed the entire room, the meeting can still be efficient. Of course everyone wants to have a say, but have the involved departments pick out the best representative. Same goes for the team; not everyone has to be in the meeting to refine the user stories. It’s not only inefficient, it’s very costly too.

#7: Define the user stories a couple sprints in advance

By making sure the user stories are clear well in advance, but not to far (max 3 sprints ahead) will help you make sure potential dependencies are taken care of. Maybe you need that expert in Java that has a very busy agenda. Maybe you need some extra hardware to run a few tests. Making sure that these things are arranged in advance will make you, and the team’s, life a lot easier.

 

These are a just a few basic tips in forming user stories. I’m curious if you have ever used some others or just really out of the box thinking in getting to know exactly what the client wants and how to tell the team what to create. Feel free to share your experience!

Share:

Related Posts

Team Moral vs happiness

Team Moral vs happiness

Failing is learning

Failing is learning