How to shrink your backlog
reducing backlog management waste 2025-09-09 #product
- Infinite backlog problem
- Incredible shrinking backlog
- Backlog abstraction layer
- How to shrink your backlog ←
Large backlogs demotivate developers, disenfranchise designers, and handicap product managers. Fortunately, you can shrink your backlog.
Segregate ideas
Other people’s ideas inflate backlogs. Even if you filter out the bad ideas (you don’t), you still won’t implement all of the good ideas. Instead, you have a product strategy that you use to decide what to develop.
To shrink your backlog, keep product ideas in a separate database, where you can organise them by customer need, and track how many customers they impact. Then reframe feature requests as product ideas.
Defer solutions
Your backlog fills up with software requirements, when you choose a solution up-front, and document its functional design in detail. In the 1990s, the tech industry decided that the eyewatering cost of this waterfall model meant that we should stop doing that.
To shrink your backlog, defer solution design until you need it. Deferring solution-space work by adopting problem-space planning, replaces hundreds of requirements with a single business problem. This also highlights actual requirements, such as compliance with legislation.
Defer design
Everyone enjoys making a quick prototype. Unlucky designers work with product managers who populate a backlog with wireframes; very unlucky designers get given clickable prototypes. While designers value input, design costs more when you don’t let them do their job.
To shrink your backlog, defer design until you need it. Stop filling the backlog with badly-designed features, and let designers focus on one problem at a time, so they can design features with good enough usability to find out if anyone wants them.
Add items later
Backlogs keep growing. First, because writing a user story takes less time than implementing one. Second, when you add backlog items for too far in the future, new priorities reduce their value, but you leave them in the backlog for ‘later’, instead of removing them.
To shrink your backlog, add items as late as possible. Only add as many as you need to avoid blocking development work, typically no more than 5–10 days in advance. Restraining yourself from writing user stories until you need them takes discipline, but avoids polluting your backlog.
Map user stories
User story mapping helps organise feature development into incremental releases. After decomposing a new feature into twenty user stories, say, you might split them across five releases, and get early feedback from each increment.
To shrink your backlog, only move stories from the story map one release at a time. Then you can limit the backlog to upcoming work, even when working on complex features in parallel. It also reduces backlog changes when you update the user story map.
Fix bugs first
Not fixing bugs causes waste that slows down development. Then you add too many items to the backlog, because they take longer than you expect to implement.
To shrink your backlog, don’t add items faster than you can make them bug free. To achieve this, implement a zero-bug policy, to make development faster and more predictable. Then you don’t need as many backlog items to accurately have enough of them.
Beyond backlogs
Product teams should stop calling planned work a ‘backlog’. Words mean things, and backlog means ’an accumulation of unfinished work’. In other domains, backlogs like unfulfilled orders or deliveries mean failure. Instead, we only need to know what to work on next.
