Why Backlogs Need a Health Review
Backlogs decay. Stories that seemed urgent six months ago no longer matter. Estimates from a year ago no longer reflect what the team knows. Acceptance criteria written before a competing system shipped now describe a feature no one wants. Yet the items remain on the backlog — not because anyone champions them, but because no one has the authority or the energy to delete them.
Most backlogs that get out of hand do so quietly, one stale ticket at a time. By the time a team notices, the backlog has become a memorial — a record of every idea anyone has had since the product began, most of which are no longer relevant. The Backlog Health Review is the deliberate ritual that prevents that drift.
What "Healthy" Means
A healthy backlog has five properties:
- Small. Total item count fits in a reviewable scope — typically a few dozen to a couple hundred items, depending on team size and horizon. Backlogs of thousands are not backlogs; they are graveyards.
- Recent. Most items were created or meaningfully updated within the last few months. Aged items are scrutinized.
- Right-sized. Items near the top are small (sprint-shaped or smaller). Items further down are larger and less defined. The distribution flows from refined to rough as you move down the list.
- Ready at the top. The next handful of items meet the team's Definition of Ready — no surprises waiting to ambush planning.
- Connected to outcomes. Most items can be traced to an active product bet, user job, or operational need. Orphan stories — items connected to nothing — are flagged.
The Review Format
A typical Backlog Health Review runs 60 to 90 minutes, every four to eight weeks. The Product Owner facilitates; the team participates. Five passes through the backlog, in order:
1. Age scan (15 min)
Sort the backlog by creation date or last-updated date. Anything older than a defined threshold (3 months, 6 months) gets reviewed. For each: is this still relevant? Has the context changed? Should it be deleted, archived, or re-prioritized?
2. Outcome scan (15 min)
Walk the top quarter of the backlog. For each item: which active bet, job, or outcome does this serve? Items with no clear answer are flagged. They may still be worth doing — but the team should know why.
3. Size distribution scan (10 min)
Look at the estimates or sizes of the top items. Are they uniformly small? Are big stories sneaking toward the top of the queue without being refined? Re-slice anything that will hit planning unprepared.
4. Readiness scan (10 min)
The top 5–10 items: does each meet Definition of Ready? Are acceptance criteria present? Are dependencies known? Anything that fails goes into the next refinement.
5. Removal pass (10 min)
The hardest and most valuable phase. The PO and team explicitly agree on items to delete. Not defer. Not archive. Delete. This is what keeps the backlog small. If the team is unwilling to delete anything, the backlog will keep growing.
What to Look For
- The "someday" pile. Items tagged "low priority" that have lived at the bottom for over a year. If they were worth doing, they would have moved up. They aren't and they won't. Delete.
- Duplicate stories. The same idea, captured by different people, at different times, with slightly different wording. Merge or delete.
- Stale bug reports. Defects logged against versions of the product that no longer exist. Verify they still reproduce. Most do not.
- Detached technical work. Refactors and infrastructure stories with no connection to active outcomes. Either re-frame them with a value statement or move them to a separate technical debt list (see Technical Debt Tracking).
- Mega-stories near the top. Items that have aged into the work queue without ever being properly sliced. Re-slice or push back down.
The Cultural Move: Deletion as a Practice
The single hardest change in adopting Backlog Health Reviews is normalizing deletion. Teams resist it instinctively — the items "might be useful someday" or "someone cared about this once." Most do not, and most won't. The act of deleting is a signal that the team values focus over completeness.
The PO usually has to lead this. A useful framing: "If we got an alert that this item would be deleted in 24 hours, would anyone fight to save it?" If the answer is no, the item is already a deletion candidate. The review is just the formal moment of acting on that.
Metrics That Help
A few simple measurements make backlog health visible:
- Total item count over time. A line going up is a warning. A flat line or a sawtooth (grow, prune, grow, prune) is healthy.
- Average age of items. Should be measured in weeks, not months.
- Items added vs. items completed vs. items deleted per period. Deletion should be a non-trivial fraction of churn.
- Time at top. How long does an item sit in the top ten before being worked? If the answer is months, the prioritization is broken.
Coaching Tips
Schedule it on the calendar.
"We'll do it when we need to" means "we won't do it." Put a recurring slot in place — every six weeks is a reasonable default.
Set a deletion target.
"By the end of this session we will have deleted at least 20 items." The constraint changes how the team participates.
Make age visible.
Most tools can color or sort by age. Use it. Old items leap off the screen once the team learns to see them.
Don't archive instead of delete.
Archive is just delete with extra clicks. If you're sure it goes nowhere, delete it. If you aren't, you haven't decided.
Tie items to outcomes.
If your tool supports labels, tag items with the bet or job they serve. Orphan items become trivial to spot.
Celebrate the prune.
Deleted-item count is worth announcing in a review. The team that takes pride in shrinking the backlog is the team whose backlog stays healthy.
Summary
A backlog is a tool, not a record. Its job is to help the team decide what to do next — not to remember everything anyone has ever wanted. Backlog Health Reviews are the small, recurring discipline that keeps the tool sharp. The teams that practice them tend to have smaller backlogs, clearer priorities, and easier planning sessions. The teams that don't tend to drown slowly in a list that no one is willing to prune.
- Pichler, Roman. Agile Product Management with Scrum. Addison-Wesley, 2010.
- Cohn, Mike. Succeeding with Agile. Addison-Wesley, 2009.
- Cagan, Marty. Inspired: How to Create Tech Products Customers Love. 2nd Edition, Wiley, 2018.