Rethinking 'User Stories': A Call for Clarity in Product Backlog Management

As someone who has spent a fair amount of time in the trenches of product development, I’ve realised that the language we use to describe our work can profoundly shape our approach to it. One term that I believe has been misused and misunderstood to the point of causing more harm than good is “User Stories”.

TLDR;

In this post, I argue that we should stop using the term “User Stories” in the system we use to store our work and conversations. Instead, we should adopt a generic term like “Product Backlog Item” to provide a more flexible and transparent framework for describing our work. This change will allow us to avoid the pitfalls of forcing all our work into a user story format and ultimately lead to more effective product development.

It may seem pedantic, but I encounter this often with teams.

The Problem with User Stories

“User Stories” has become a staple in many development teams’ lexicon. However, I’ve observed that it often leads to tunnel vision, where people try to shoehorn every piece of work into a user story format, even when it doesn’t make sense.

For instance, consider these examples:

• “As a developer, I want to have some documentation so that I know what I am doing” instead of simply saying, “Update the documentation.”

• “As a Product Owner, I want to support 10k simultaneous users, so that I can serve more transactions” instead of just stating, “Must support 10k simultaneous users.”

In these cases, the user story format adds unnecessary complexity and can even obscure the work’s true nature. It’s like trying to fit a square peg into a round hole - it’s not only difficult but also distorts the original shape of the peg.

A Better Approach: Product Backlog Items

I propose replacing “User Stories” with a more generic term: “Product Backlog Item”. This term refers to an item in your list of things to do, without any assumptions about its format or structure.

Yes, I know I’m slightly biased as a Scrum Trainer, and “PBI” or “Product Backlog Item” is my comfort terminology. How about “Rock” or “Item” instead?

This change will give the author of the work the freedom to write backlog items in the way that best communicates their content. It will also help to avoid the confusion and miscommunication that can arise from trying to force all work into a user story format.

Consider the freedom and clarity that comes with writing “Update the documentation” or “Must support 10k simultaneous users”. These statements are direct, clear, and free from the constraints of the user story format. They allow the creator to express the work to be done in the most effective way possible, maximising the transparency of the content.

I should note that I have no problem with the user story format when we are talking about genuine user stories. But if there is no user then there is no user story.

The Impact of Language on Product Development

Language is not just a tool for communication - it also shapes our thinking and our behaviour. In the realm of product development, the terms we use to describe our work can influence how we approach it, organise it, and understand it.

By using the term “User Stories”, we implicitly endorse a specific way of thinking about our work that may not always be helpful or appropriate. We encourage people to think about user needs and benefits, even when there are more effective ways to describe the work to be done. This is perfectly valid when the context supports it.

By switching our naming to “Product Backlog Items”, we can free ourselves from these constraints and open up new possibilities for thinking about and organising our work. We can create a more flexible and adaptable framework for product development that is better suited to our work’s complex and varied nature.

Conclusion

Language matters in product development. We can improve communication, increase transparency, and ultimately build better products by rethinking how we describe our work. So let’s say goodbye to “User Stories” and hello to “Product Backlog Items”. Let’s embrace a more flexible and transparent approach to product development, one that recognises the complexity and diversity of our work and gives us the freedom to describe it in the most effective way possible.