Why Your Backlog Keeps Growing

The typical response to a stale, bloated backlog is to prioritise better.

Run a workshop. Pick a framework. Stack-rank everything. Cull the bottom third. Repeat next quarter.

I've done this. It helps in the short term. But I've come to think it usually treats the symptom rather than the cause.

Why backlogs exist in the first place

Backlogs are a natural byproduct of building fast.

If you are moving quickly, you will accumulate bugs you did not have time to squash, small improvements that did not make the cut, and ideas that surfaced mid-sprint and got parked. That is not a failure. It is evidence that the team was focused.

If a product team has no backlog at all, that is often worth interrogating. It can mean the team is not moving fast enough, or that work is getting quietly absorbed rather than tracked.

So the presence of a backlog is not the problem. The problem is when it grows without a clear plan for working through it.

The actual problem: no strategy for the backlog

A growing backlog usually means not enough is leaving. That part is obvious.

What is less obvious is why — and in my experience, the answer is usually that the team has not made an explicit strategic choice about how they intend to work their backlog down.

There are a few reasonable approaches, and they are meaningfully different:

• Continuous allocation: reserve a fixed percentage of team capacity each sprint — say 20% — specifically for backlog work. It never gets crowded out because it's built into the budget.
• Batch periods: run focused bug-squashing or debt-clearing sessions on a regular cadence, like two days every fortnight or a dedicated week each quarter.
• Zero backlog policy: tackle issues as soon as they surface and do not allow them to accumulate. Some teams operate this way by default — it creates a different kind of urgency and requires strong triage discipline.

None of these is universally right. But without a deliberate choice, the backlog typically grows by default. New work gets added continuously. Backlog items get deprioritised in each sprint planning because they do not compete well against the next feature. Over time the pile gets noisier, older, and harder to act on.

The prioritisation workshop does not fix this because it does not answer the underlying question: when and how is this team going to actually work through its backlog?

The strategy does not have to be fixed

One thing worth saying explicitly: backlog strategy does not have to stay the same for the lifetime of a product. It should change when the context changes.

The right approach often depends on where the team is in its current cycle.

After a big launch — especially if the team pushed hard to hit a deadline and accumulated debt along the way — it can make sense to spend a sprint or two deliberately working through the backlog. Engineers address the bugs and rough edges. The product team, freed from feature delivery pressure, gets space to do proper discovery and figure out what the next meaningful problem to solve actually is.

That is a real strategy, not a consolation prize. It is a deliberate decision to stabilise the product and create the conditions for the next phase of growth.

In a different quarter, when there is a clear market opportunity and the product is in decent shape, continuous allocation at 20% might be enough. In an earlier-stage team that is still finding product-market fit, zero backlog may not even be the right goal — shipping fast and learning quickly matters more than clean ticket hygiene.

The point is that the strategy should reflect current conditions, not just default to "we will get to it eventually."

My current view

A growing backlog is not primarily a prioritisation problem. It is usually a sign that the team has not committed to a clear strategy for how it will work through accumulated work.

The shape of that strategy can vary. It can evolve over time. But it needs to exist.

Without it, you can reprioritise the pile as many times as you like. It will keep growing back.