Why your backlog is lying to you

When a digital platform's delivery is slow, the instinct is usually to look at the backlog. Too many items. No clear priority. Things sitting untouched for months. The team is busy but progress is unclear.

This is not unusual. In my experience of working across global digital platforms, most enterprise backlogs share the same problem. They tell you what was asked for. They do not tell you what matters.

The backlog is a symptom. The operating model is the diagnosis.

The first thing I do when reviewing a platform environment is stop looking at the backlog and start looking at the business. What are the actual commercial and strategic priorities this quarter? What does the roadmap say versus what the development team is actually working on? Where is the disconnect between what stakeholders believe is happening and what is in the sprint?

In most cases the backlog problem is not a backlog problem at all. It is an operating model problem. Work is flowing into the backlog from too many directions, with no consistent criteria for what gets in, no consistent way of expressing priority, and no regular mechanism for removing things that no longer matter.

A diagnostic process that works

Rather than going through hundreds of items one by one and asking "is this still relevant?", work backwards from value.

Start by mapping the backlog against the business roadmap. If an item cannot be traced back to a current business objective, park it immediately. Not deleted. Parked. This alone typically removes a significant proportion of items from active consideration.

Next apply a simple value classification to everything remaining. Tag each item as one of: Key Business Item, Improvement, Bug or Issue, Technical Debt, or Other. This sounds basic but it immediately makes the backlog readable. You can scan it and understand the shape of the work in thirty seconds.

Then look for duplication. In a backlog that has grown organically, the same business objective often exists as multiple features in different states of refinement. Consolidate them into a structured, value-led roadmap where each item has a clear owner, a clear priority, and a clear link to a business outcome.

Done properly, this process can reduce a backlog substantially. Not because you threw work away, but because you established what the backlog is actually for.

What a backlog is actually for

A backlog is not a to-do list. It is not a historical record. It is not a parking lot for ideas that might be useful someday.

A backlog is a prioritised queue of work that the team is genuinely committed to delivering, in roughly the order it will be delivered, with enough clarity that any developer could pick up the top item and know what done looks like.

If your backlog does not meet that definition, the issue is not the volume of items. The issue is that your backlog does not yet have a clear owner with the authority and the process to enforce that definition.

The fix is structural

Before touching a single ticket, ask these questions. Who has the authority to say no to new backlog items? What is the criteria for something entering the backlog at all? How often is the backlog reviewed and rationalised? Is the roadmap connected to the backlog, or do they live in separate tools with separate owners?

If you cannot answer those questions clearly, the backlog will grow back within months of whatever cleanup you do today.

Most delivery problems are not delivery problems. They are ownership problems. Start there.