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”. 


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.


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.

Upcoming Training Opportunities

These are the next five classes we have, and you can check out our full public schedule of classes.

Immersive Professional Scrum Product Owner with Russell Miller over 8 weeks starting 11th October 2023
Virtual Immersive
11 Oct-13 Oct, 2023
09:00-13:00 EDT
8 weekly half-days
Immersive Applying Professional Scrum with Simon Bourk over 10 weeks from18th October 2023
Virtual Immersive
18 Oct-20 Oct, 2023
09:00-13:00 EDT
10 weekly half-days
Immersive Professional Agile Leadership Essentials with Joanna Płaskonka Ph.D. over 7 weeks from 20th October 2023
Virtual Immersive
20 Oct-1 Oct, 2023
09:00-13:00 BST
7 weekly half-days
Live Virtual Product Backlog Management Skills with Joanna on 2nd November 2023
Virtual Traditional
2 Nov, 2023
09:00-17:00 GMT
1 full-days

We can deliver any of our courses as private in-house training over Microsoft Teams & Mural. We also recommend training based on your accountabilities or role, you can go directly to recommended courses for Scrum MastersProduct OwnersDevelopers and Agile Leaders.

Create a conversation around this article

Share on Facebook
Share on Twitter
Share on Linkdin

Related Courses

No items found

Read more

Martin Hinshelwood
🚀 Navigating the intricacies of the Sprint Goal in Scrum? 🎯 Discover the essence of crafting a goal that drives real value! 📈 Dive deep into the tactical steps, avoid common pitfalls, and ensure your team is on the right track. 🛤️ Let’s demystify the Sprint Goal together! 🤝 #Scrum …
Martin Hinshelwood
Software Development is not just a systematic process but a dynamic interplay of critical work that shapes the progress of your product. A Scrum team’s work can be classified into Sprint work and Refinement. To steer your Scrum Team towards success, it’s essential to understand, manage, and balance these two …
Daryn Basson Would you recommend the APS course to a newbie scrum team, and Why? Why the APS Course is a Must for Newbie Scrum Teams In this article, I’d like to share some thoughts on the Agile Practitioner Series (APS) course and its relevance to newbie Scrum teams. But first, …
Martin Hinshelwood
🚀 Navigating the nuances between the Definition of Done and Acceptance Criteria? 🤔 Dive into our latest article that explores the sanctity of a working, usable product without compromising value. 💡 Let’s ensure quality and value go hand in hand! 🤝


We believe that every company deserves high quality software delivered on a regular cadence that meets its customers needs. Our goal is to help you reduce your cycle time, improve your time to market, and minimise any organisational friction in achieving your goals.

naked Agility Limited is a professional company that offers training, coaching, mentoring, and facilitation to help people and teams evolve, integrate, and continuously improve.

We recognise the positive impact that a happy AND motivated workforce, that has purpose, has on client experience. We help change mindsets towards a people-first culture where everyone encourages others to learn and grow. The resulting divergent thinking leads to many different ideas and opportunities for the success of the organisation.