Why Product Backlogs Turn Into Graveyards

“Add it to the backlog.” The phrase is so common in product meetings that it has stopped registering as a decision. It sounds like a commitment. It is closer to a polite refusal. The item is not going to ship soon, the team does not want to debate why, and the backlog is the only place that allows the conversation to end without anyone having to say no.

Over enough quarters, this pattern produces backlogs that look like queues and behave like graveyards. The items are sorted by priority. They have been sorted by priority for two years. The first hundred items have not moved. The team grooms them ritually, adjusts the order slightly, and ships almost none of them. Anyone who has worked in product long enough has seen this pattern, and most teams pretend it is a temporary condition that better prioritisation will solve.

It is not a prioritisation problem.

What backlogs accumulate, and why they stop being readable

A new backlog is short and legible. Each item maps clearly to a known user need or a recent piece of research. The team can read the backlog and recognise the work the company is doing. After two years, the backlog contains items added by former employees, items added in support of strategies the company has since abandoned, items added to placate stakeholders whose priorities have changed, and items added to capture user feedback that nobody has time to act on but nobody wants to be seen ignoring. The backlog is no longer a queue. It is a record of every direction the team almost went.

The team can no longer read it. Reading it would take a full day. The team grooms the top fifty items, ships from the top ten, and treats the remaining several hundred as a kind of organisational subconscious. The grooming is performative, because the items being groomed are mostly already in the right order and the items below them will not be touched.

The performance has a cost. Each grooming session burns hours of the team’s most expensive people debating the relative priority of items that the team already knows it will not ship. Stakeholders who attend the sessions form opinions about why their items are not advancing. The grooming becomes the political surface where every team’s resentments about not being prioritised get rehearsed, with no chance of resolution because the resolution would require admitting that most items are not going to ship.

This is the wrinkle. The backlog has become a place to hold disagreements rather than to schedule work, and the team has not noticed the substitution.

Why deletion is harder than addition

The asymmetry between adding to the backlog and removing from it is structural. Adding is a neutral act. Anyone can add an item, the addition costs the team nothing immediately, and the addition signals that the team is taking the request seriously. Removing is a political act. The remover is implicitly saying that the item does not matter enough to keep. The original requester, if still around, may push back. The team that wrote the item, if it was driven by research, may interpret deletion as a dismissal of the research.

So nothing gets deleted. The backlog grows. Within two years, eighty per cent of the items in the backlog are items the team will never ship, and the team knows this, and nobody will say it.

The fix is structural, not procedural. The team has to install a default behaviour that reverses the asymmetry. The default has to be that items expire. An item that has been in the backlog for two quarters without advancing is closed by default at the end of the quarter, with a one-line note explaining why. The closure is not a judgement. It is a reset. The item can be re-added if it turns out to matter again. Almost no items get re-added, which is the entire point.

A team that adopts this default usually goes through a difficult quarter. The first round of expirations triggers stakeholder pushback. Items that had been quietly held in the backlog as evidence that the team was listening get closed, and the stakeholders who had been pacified by the holding pattern have to be told that the holding pattern was a polite fiction. This is the cost of the reset. The cost is real. The cost is also one-time.

After the difficult quarter, the team has a backlog that contains only items the team intends to ship in the next two quarters. The grooming sessions become useful, because the items being groomed are real. The stakeholders learn that the team will close their items if the items do not advance, and they begin to prioritise their own asks more carefully. The backlog stops being a graveyard and starts being a queue.

What the backlog is supposed to remember and what it is not

A useful framing for what belongs in a backlog is the question of what the team is going to act on in the next six weeks. Items that fit are in. Items that do not fit are not in. Research findings, user feedback, strategic ideas, and competitive observations all matter to the team, but most of them do not belong in the backlog. They belong in a research log, a feedback document, a strategy doc, or a competitive watch list, depending on which they are.

The conflation of all four into the backlog is one of the main reasons backlogs become unreadable. The team starts using the backlog as the universal repository for everything anyone ever said about the product, and the backlog stops being able to do its actual job, which is to schedule work the team will perform soon.

A team that separates these artefacts ends up with a thinner, more honest backlog and a richer set of supporting documents. The research log is read by anyone designing or building. The feedback document is reviewed monthly by product to surface emerging patterns. The strategy doc is updated quarterly. The competitive watch list is read by leadership. None of them are mistaken for the backlog. The backlog contains only the work the team is going to do.

This separation is administratively annoying for a quarter and structurally calming forever after. The annoyance is the cost of the discipline.

The roadmap, which is the backlog’s louder cousin

A backlog that has become a graveyard is usually accompanied by a roadmap that has become wishful thinking. The roadmap shows the team’s intended work over the next six to nine months. Every column on the roadmap maps to a sequence of items in the backlog. The team uses the roadmap to communicate intent to stakeholders. The roadmap reflects the backlog. The backlog reflects the team’s accumulated intentions. The intentions reflect what was true two years ago, plus a few quarters of new arrivals.

The team that fixes the backlog also has to fix the roadmap. A roadmap built on top of a graveyard is fiction the team has been telling for so long that the team half-believes it. Resetting the backlog forces the roadmap to be redrawn against current intentions, which is uncomfortable in the short term, because the new roadmap will be shorter and less impressive. The shorter, more honest roadmap is also the one the team can actually deliver, which is the only kind worth communicating.

A team that treats this transition as an embarrassment will drift back to the graveyard within a year. A team that treats it as the correction it is will stay on the new path. The difference is usually whether the leadership has the appetite to communicate a smaller plan with higher confidence, instead of a bigger plan with lower confidence. Most stakeholders, when given the choice clearly, prefer the smaller plan. The fear of asking for it is mostly a fear the team carries, not a fear the stakeholders confirm.

The backlog that gets pruned earns the team the trust to carry the smaller plan.