900 Issues in the Backlog. I Closed Hundreds and Nobody Was Upset.

My very first consulting engagement ever, and I was brought in a few months after it started. Six consultants from the agency that hired me were already working with the client. The client was large and had a lot of skilled people. Somehow the backlog had grown to 900 issues, unprioritized, a mess, with four different workstreams running and duplicated effort across them.

I was brought in to work with the PMO and get a handle on it. What I actually did was become the decider.

I started from the top – vision, mission, strategy, what are we actually trying to do here – used that as the filter, and ruthlessly closed everything that didn't match. Hundreds of tickets. If there wasn't a strong answer to "why," it was gone.

I braced for the fight. Not one person was upset. Not the VP who sponsored the project, not the PM, not the most junior developer, not the business analyst who had personally entered hundreds of those tickets.

That reaction is the whole lesson, and it took me a while to understand it.

"Just add it to the backlog" is avoidance wearing the face of diligence

Here's the pattern I diagnosed, and I've seen it at every size of company since.

People are afraid an idea will get lost, or that they'll do the wrong thing and be blamed for it. So it becomes "just add it to the backlog – no harm, right?" It feels like the safe option. It costs nothing, it's reversible, and nobody can accuse you of dropping something.

But there is harm. A large amount of work in progress and a bloated backlog create a cognitive load that overwhelms people and can lead to paralysis. Seeing 900 open issues makes a team feel like it's drowning, and a team that feels like it's drowning makes worse decisions about everything, not just about the backlog.

The tell is that nobody actually wanted the tickets there. They weren't defending a queue of valuable work. They were relieved to have someone take responsibility for a decision none of them felt authorized to make, and the reason it read as relief rather than loss is that closing those items didn't destroy anything. It named what was already true.

Closed is not gone, and that's what makes it safe

The objection I get is always the same: what if we need it later?

In a ticketing system, closed doesn't mean deleted. You can always find it again. You just can't hoard it in the backlog forever, because the hoard is what's doing the damage – not the individual items, the mass of them.

Once people understand that closing is reversible, most of the resistance evaporates, and what's left is usually one person with two or three items they genuinely believe in. That's a good conversation to have. It's a much better conversation than the one where nobody can find anything because there are 900 candidates.

Clarity about priorities is clarity about what not to do. You figure out vision, mission, and strategy, you use that as the filter, and you close everything without a strong answer to why. It is better to make the decision and do the work than to defer it by tossing every idea onto a pile.

The named version of this failure

The pattern has a name now. A 2026 analysis of software delivery failure calls it the Backlog Illusion: a team that "looks productive on every velocity chart while shipping nothing a customer would pay for." Their sharper phrasing is that the Backlog Illusion is "a team busy delivering features no validated requirement asked for."

I'd take that source with some salt – it's a vendor selling requirements tooling, and its own chain of citations runs through a methodology I wouldn't lean on. But the name is useful, and it points at the right thing: the illusion isn't that the team is working. The team is definitely working. The illusion is that the backlog represents demand.

The conditions that let a backlog bloat

Two numbers from the 2026 product-management survey data explain why this happens even to teams that know better.

Half of respondents – 49% – cite resource and capacity constraints as the top cause of roadmap misalignment, with shifting priorities from short-term commitments close behind at 47.5%. The report's own read is that misalignment is driven "less by weak strategy and more by execution pressure, where limited capacity and short-term demands consistently override longer-term product intent."

And 7.4% of organizations have no clear decision-maker for prioritization at all. When nobody owns the decision, deferral isn't one option among several. It's the only move available to the person holding the idea, and the backlog is where it goes.

That's the structural point. Backlog bloat is rarely a discipline failure by individuals. It's what a system produces when it hasn't assigned anyone the authority to say no.

How to run the cull without it becoming a fight

If you're going to do this, a few things make the difference between relief and revolt.

Do the strategy work first, visibly. The filter has to exist before the closing starts, and people have to be able to see it. A cull without a stated filter reads as arbitrary, and arbitrary is what generates the fight. When the filter is explicit, the conversation moves from "why did you close mine" to "does this match the strategy," which is a conversation about the work rather than about you.

Close in bulk, review on request. Don't negotiate item by item; you'll be there for weeks and you'll lose your nerve somewhere around hour six. Close the block, announce it clearly, and invite anyone to make a case for bringing something back. In my experience very few people take you up on it, and the ones who do are usually right.

Say out loud that closed is findable. Most of the anxiety is about permanence, and most of it dissolves in one sentence.

Name who decided. Not to take credit – so that the accountability is unambiguous and nobody else is left holding a risk they didn't choose.

What I'd do differently now

Two things.

I'd do it earlier, and I'd do it as a standing practice rather than an event. A once-a-year cull is a heroic intervention that fixes a symptom; a filter applied every time something is proposed prevents the accumulation. The filter is the same either way – is there a strong answer to why, and does it serve the strategy.

And I'd be more explicit that I was taking the blame. The reason that engagement went smoothly wasn't my judgment about which tickets to close; I got some of those wrong, certainly. It was that one person visibly owned the consequences, so nobody else had to carry the risk of a decision they weren't empowered to make. Give the credit and take the blame – if I make the wrong call, I own the consequence, and that's what makes it possible for anyone else to relax.

In twenty-plus years, the thing I keep relearning is that 99.9% of the time, things have not gone wrong. We let fear of the negative consequence dictate our actions, and if we're open, honest, thoughtful, and working hard, things generally go fine.

Nobody wants 900 tickets. They just want someone to say so.