blog

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

Published on
4 minute read

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:

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.

agility discovery-ideation blog featured homepage product-backlog-item product-backlog-management user-stories

Connect with Martin Hinshelwood

If you've made it this far, it's worth connecting with our principal consultant and coach, Martin Hinshelwood, for a 30-minute 'ask me anything' call.

Our Happy Clients​

We partner with businesses across diverse industries, including finance, insurance, healthcare, pharmaceuticals, technology, engineering, transportation, hospitality, entertainment, legal, government, and military sectors.​

New Signature Logo
Emerson Process Management Logo
Lean SA Logo
Slicedbread Logo
Ericson Logo
Alignment Healthcare Logo
Xceptor - Process and Data Automation Logo
Cognizant Microsoft Business Group (MBG) Logo
Boeing Logo
Capita Secure Information Solutions Ltd Logo
SuperControl Logo
Deliotte Logo
MacDonald Humfrey (Automation) Ltd. Logo
Big Data for Humans Logo
Kongsberg Maritime Logo
Lockheed Martin Logo
Milliman Logo
Brandes Investment Partners L.P. Logo
Nottingham County Council Logo
New Hampshire Supreme Court Logo
Royal Air Force Logo
Washington Department of Enterprise Services Logo
Department of Work and Pensions (UK) Logo
Ghana Police Service Logo
Boeing Logo
Slicedbread Logo
Philips Logo
Teleplan Logo
SuperControl Logo
Qualco Logo