TL; DR: The Oversized Product Backlog Problem — When Noise Interferes with Signal
There are plenty of failure possibilities with Scrum. Given that Scrum is a framework with a reasonable yet short “manual,” this effect should not surprise anyone. Neglecting the critical Scrum artifact for continuous value creation is one of the common Scrum anti-patterns. If your Scrum Team strives to make your customers’ lives easier Sprint after Sprint, beware of the oversized Product Backlog.
📺 Join me and explore the consequences of inadequate Product Backlog management in less than three minutes.
Update: I am running a poll on LinkedIn—join the voting: “What reasons have you observed why Scrum Teams stuff their Product Backlogs — a very costly pattern that diminishes ROI and value creation?”
🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 31,000-plus other subscribers.
🎓 Join Stefan in one of his upcoming Professional Scrum training classes!
Join more us on July 6, 2021, for the Hands-on Agile #32: How to Win with Agile Resistant Teams—Scott Weiner.
The Product Backlog According to the Scrum Guide
The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.
Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs.
Source: Scrum Guide 2020.
Scrum is about figuring out what is worth building to improve your customers’ lives while mitigating risk in a complex environment. Literally, we do not want to bet the farm on a hunch what customers will purchase in the future.
For that purpose, you want an actionable Product Backlog that reflects the best use of the developers’ time at any given moment. To achieve that level of fitness, your Product Backlog needs to be trimmed. Remember: The Product Backlog is about product delivery, not product discovery. So, handle the latter somewhere else to avoid cluttering the Backlog itself.
Oversized Product Backlogs
The symptom: The Product Backlog of your team comprises hundreds of entries, from user stories to ideas to hypotheses and experiments to documentation fragments—you name it. Dumping everything into the Product Backlog—probably in the name of transparency—poses a massive challenge for various reasons:
- Garbage in, garbage out: Increasing the quantity of input does not increase the outcome of the Scrum Team’s work. In other words: Being “busy” ≠ providing value to customers & the organization.
- The Product Backlog is the Scrum Team’s best chance to identify every Sprint the best way ahead to make your customers’ lives easier. Hence you need signals, not noise. Too many entries may make teammates less inclined to engage in the Product Backlog refinement actively.
The solution: Apply the Goldilocks principle—“just right”—and find your balance as a team. Then, dump the rest. You want an actionable Product Backlog that comprises eight to maybe twelve weeks of work. Be warned, though: Typical objections to deleting unnecessary Product Backlog items range from “we cannot delete them—it is our documentation as required by governance” to “we invested so much work in creating them.” (The former is a form of loss aversion, the latter a manifestation of the sunk cost syndrome.)
Cannot see the form?
Please click here
The XXL Product Backlog Problem — Conclusion
An oversized Product Backlog looks good at first glance only to reveal at the second that your organization seems to value output over the outcome. However, creating a humongous backlog of tasks and keeping the “resources” constantly busy will not create value for your customers. On the contrary, clinging to the old industrial paradigm thinking while practicing Scrum will inevitably lead to bad production decisions. Thus, having an oversized Product Backlog will reduce the organization’s return on investment while we could serve our customers better at the same time.
Is your organization also prone to fall for the oversized Product Backlog, thus impeding Scrum? Please share them with us in the comments.
✋ Do Not Miss Out: Join the 10,000-plus Strong ‘Hands-on Agile’ Slack Team
I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.
If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.
📖 Related Posts
Product Owner Anti-Patterns — 31 Ways to Improve as a PO
28 Product Backlog and Refinement Anti-Patterns
Three Wide-Spread Product Owner Failures in 6:09 Minutes—Making Your Scrum Work #5
Sprint Acceptance Gate? — Making Your Scrum Work #4
A Sprint Review without Stakeholders — Making Your Scrum Work #3
Download the Scrum Anti-Patterns Guide for free.
📅 Learn about Avoiding the Oversized Product Backlog by Attending Our Scrum Training Classes, Workshops, and Events
See all upcoming classes here.
You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.
