Is Your Backlog Too Big? A New Technique for Prioritization
Focus on points of differentiation and de-prioritize points of irrelevance
How many items are in your product backlog? 50? 100? 500? A favorite tactic for product managers dealing with stakeholder suggestions is to tell them they ‘will put it in the backlog.’
Unfortunately, many backlog items will languish in the backlog for months or even years before being prioritized for a Sprint. Many years ago I inherited the product management of a B2B SaaS Managed File Transfer solution. The backlog had over 300 items.
On average we completed 8 items per Sprint. It would have taken us 3 years to complete all the items in the backlog, assuming no new items were discovered or added. Is your Backlog too big? And are there some new techniques you can use to prioritize it?
In this article we will talk about:
- The challenge of backlog prioritization
- Putting items in the backlog to placate stakeholders is not a solution
- Focus on points of differentiation, de-prioritize points of irrelevance
The Challenge of Backlog Prioritization
As described in the Scrum Guide, the Product Backlog is an emergent, ordered list of what is needed to improve the product. A good backlog is dynamic — new items are discovered and added, existing items are prioritized, and some items are eventually deleted.
Good product backlogs exhibit similar characteristics. Roman Pichler and Mike Cohn coined the acronym DEEP to summarize several important characteristics of good product backlogs: Detailed appropriately, Emergent, Estimated, and Prioritized. Bill Wake stated that good backlog stories demonstrate INVEST (I — Independent, N — Negotiable, V — Valuable, E — Estimable, S — Small, and T — Testable.
There are many ways to prioritize a backlog. Ten of the most popular approaches include: