Write better user stories with INVEST

User stories come in all shapes and forms. Some teams like to be expressive and write a full blown requirements document for each feature. Others lack a vision and only focus on implementation details. Some overburdened product owners take shortcuts and write stories which start with “As a user…” and zero details beyond the title. We will highlight common problems of user stories and introduce you to a simple acronym which can help improve your user story’s quality.

Symptoms of bad user stories

Missing the Why

Bad user stories don’t justify themselves. They are the equivalent of “because i said so” parenting. Even if you’re not consciously aware of this you are using formal role power to make the team do such tasks. This is bad for multiple reason. The most important one is that it discourages collaboration. Your are starving the team off an opportunity to give their input by withholding information. This is incredibly inefficient and frustrating for the team.

Explaining the Why on the other hand gives the team a great opportunity to come up with novel ways to achieve the desired outcome.

Missing the What

A symptom of a story lacking important details is that the team discovers hidden dependencies during development. Another issue might be that they are not sure when it is done or are not able to test it. Do you encounter user stories which the team struggles to estimate? It might also be missing important details.

How do you know when you’re done?

Be sure that everyone knows what needs to happen within a user story. You will reduce surprises during your sprints and have stories completed much more efficiently.

Zooming in on the How

Once we encounter problems we instantly think of solutions. It is easy to get obsessed with a certain solution. But instead of mapping out all the details of your grand solution you should focus on the desired outcome instead. User stories which obsess on the How instead of the What usually have weak or no acceptance criteria and a long description of implementation details.

Especially if you have transitioned from an engineering role into a product management role it is hard to let go of the implementation details and focusing on the outcomes.

Principles of successful user story writing

While the above patterns are common they are surely not the only issues a user story can contain. Unclear stories make unpredictable, inefficient sprints. They demotivate the developers. It spawns an environment of “them versus us” thinking.

You want to ensure that you document your user stories, have meaningful discussions around them and confirm that everyone has the same understanding. Easier said than done. How can we achieve this?

Collaborate with the team

Involve the team as early as you can and the team is willing to. You are in this together. All too often it happens that the engineering team retreats into their domain, the technical implementation. By letting them participate in product decision you strengthen their sense of ownership. This is motivating on the one hand and leads to objectively better results on the other hand. As a product owner or product manager you carry a lot of responsibility on your shoulders. You have a team of experts around you and it would be foolish not to leverage their insights and creativity to improve the product.

Establish a “Definition of Ready”

If you’re eager to improve your user stories it’s easy to fall into the trap of over-optimising. However, it’s important that you do not waste time creating the perfect user story template or adding every little detail to the ticket. Good enough is good enough in this case. But how do you know then when a story is prepared well enough?

To resolve this uncertainty you can simply establish a Definition of Ready. Think of it as a little checklist you can go through with the team to assess whether a story is good enough.

The INVEST principle

The INVEST acronym is a very common to determine the quality of a user story. It works great as a Definition of Ready. But what does INVEST stand for and how can it be interpreted?

Independent

Could we start working on this story right now?

The “independent” criteria is rather self explanatory. However, there are multiple aspects to it which I would like to mention: According to Wikipedia the story should be self-contained, in a way that there is no inherent dependency on another story. However, in big organisations the dependencies within your backlog are less of an issue than are dependencies to other teams or stakeholders outside the team. You should definitely consider any constraint which is outside your backlog as well.

Negotiable

Do you still have some creative freedom on the story?

It’s easy to miss some details while writing user stories. But when you’re too obsessed with writing perfect user stories it might happen that you over-specify what needs to happen. Do not turn your user stories into full blown requirement documents. Be sure to leave room for some creativity of the team members. This is what the N in INVEST stands for.

Valuable

To me this is the most important question you have to ask yourself. And I think it does not even go far enough. With a bit of creativity you can almost always find one way or another how your story might deliver some value to some stakeholder or user.

Is this valuable enough to spend our time on it?

Here it is time to be hard on yourself and save the team and organisation a lot of pain and money. Rather than asking for value you should ask yourself if this is valuable enough to spend the team’s time and organisation’s resources on it. Consider which users are affected, how much revenue you can generate or which risk you reduce for the organisation. Empower the team to question the numbers and insights coming from the business side.

Estimatable

Do we have all the details to roughly predict the scope and effort of this story? If not the story is probably too big or you’re missing crucial details. Be aware that this does not mean that the story has to be estimated already or that you have to estimate at all!

Small

Can one team member finish this story within half of the sprint?

What is small enough for a user story? Some say a single story should not take more than 2/3 of a sprint. I personally think a good metric is whether a single team member could complete the story within half of the sprint.

Testable

Can you verify each acceptance criterium is fulfilled?

If you can’t test whether the acceptance criteria of your story is fulfilled how can you make sure you have completed the story? Do you often have to create follow-up stories or stories tend to get stuck in the “To Test / Review” column? Then you might have issues with unclear acceptance criteria. If that is the case you should take some extra time to talk about how you are going to test that the acceptance criteria is fulfilled. This is even more important if you do not have a dedicated Quality Assurance person or team. As a product owner you should be able to take care of that yourself as well.

Benefitting from better user stories

Investing a bit of effort and time into your story writing and refinements goes a long way. It helps identify issues early on and squeezes more value out of your precious sprint time. This brings a big benefit to the end user and your organisation but also it is a bliss for an engineer to work on a user story which is well defined. Ultimately it makes the product owner’s job a lot easier as since it prevents many surprises during your sprints. By using INVEST as a simple checklist for your stories you can already reap many of the benefits described above. Give it a try!