The Oversized Product Backlog Problem
Making Your Scrum Work #11
Join the DZone community and get the full member experience.Join For Free
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.
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 and 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.)
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.
Published at DZone with permission of Stefan Wolpers, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.