We cannot define what a "Good User Story" is… And it does not matter

Why the product backlog?

Product: cost and value in a backlog

To define the product backlog, I would like to introduce a quite simple definition of a product. A product is anything that a company can make, that will bring value to a customer, and for which the company expects to be paid. The cost is the sum of all the resources spent to make the product, and the value is the sum of all the benefits the customer will get from using the product. The payment is what the company expects to get in exchange for the value delivered.

The essential element that is lacking in this definition is the connection between the product and the customer. The product backlog is the tool that allows us to make this connection explicit, by listing all the features, tasks, and requirements that must be implemented to bring value to the customer.

Not everything must be agile

In the previous schema:

1. The purpose of the product is defined by the customer
2. The expected user experience is completely defined
3. Every step of the implementation is planned
4. Only then the development starts
5. And the product is released when finished

Here, the purpose of product backlog items is to:

• Define all tasks for the development team
• Estimate their complexity or development time or budget
• Plan according to dependencies between items
• Ensure that the sum of items will make the expected product
• Monitor anytime that the project is on track

This process is very much not agile. In the rest of this article, we consider a different approach.

The agile user story

Individuals, interactions, and customer collaboration

Agile or not, we have seen that one essential purpose of a user story is to facilitate communication between the development team and the customer.

One essential characteristic of an agile user story is that it is meant to be discussed, not just written. It is a tool for collaboration.

1. We want the customer to discuss the user story
2. We want the development team to discuss the user story

It means that a story is not some static piece of information, but a living document that evolves as the team and the customer learn more about the needs and the solution.

Priorities and roadmaps, or responding to change

I have often read that one essential purpose of a user story is to help with release planning. The essence of the release planning meeting is for the development team to estimate each user story in terms of ideal programming weeks.

We want roadmaps, we want to know when things will be done. At the same time, we want to be able to respond to changes. It seems contradictory.

• Hierarchical roadmaps: more details and more confidence for the short term
• Temporary roadmaps: they must be constantly updated to respond to changes
• Absence of commitment: there should be a disclaimer about what is and is not a commitment

This is another difference between product ownership and project management.

So many frameworks

INVEST principles

The acronym INVEST was coined by Bill Wake to determine what is a good user story and what is not, and is still widely referenced.

Independence means that each user story could be implemented independently.

A negotiable user story is a user story where details are not yet defined and are meant to be the result of discussions between the development team and the customer.

A story must be valuable. This is the most important characteristic of a user story.

A story should be estimable, meaning that we should be able to guess how long the story will take to implement.

A story should be small. This relates to the estimable characteristic.

And finally, a user story should be testable. The first point is to avoid technical debt with unit, integration, and regression tests.

Many frameworks, many complaints

Frameworks in general can be very good tools:

• They can guide us when we don’t know where to start
• They can be ubiquitous enough to ease communication with shared patterns
• They can guarantee no part of the process is missed, every step is documented
• They can guarantee consistency in our work, always using the same pattern
• They can improve efficiency, not having to reinvent the wheel

So why are there so many competing frameworks if they are supposed to give the whole solution?

Similarly, there are no obvious ways to follow the INVEST principles.

For example, what should we do with a not-small-enough user story?

• We can try and make it smaller by removing anything that does not bring value
• We should split in smaller user stories
• We should consider the user story to be an epic containing user stories
• We should organize user stories by epics and themes

All these ideas make sense. The product backlog by nature cannot be homogeneous.

Can we be agile?

Following a framework is not a purpose

Applying frameworks blindly is extremely dangerous. I have the same opinion in software engineering, where there are many frameworks and libraries. The main danger of frameworks is that sometimes they lead us to change many different parts of the process, and we must remind ourselves of why we wanted user stories.

We want different things

Continuous discovery — The product backlog is the result of the continuous discovery process.

Prioritization — User stories are meant to help prioritize the work to be done.

Continuous delivery — User stories are meant to guide the development team on what to build.

When we realize that we manipulate user stories with many different purposes, instead of trying to build the perfect product backlog with perfect user stories, we need product management.

I did not give a definition of a good user story, and well, user stories are very useful when they allow interactions between teams. No framework is ever going to guarantee this; it is the hard job of the product owner to do so. We should use all the tools we have only to the extent that we can verify they help us with the outcome.

The quality of a user story has very little to do with what is written on the card; its success can only be measured by the interactions and collaborations it created.