← Back to Insights

The backlog wasn't messy because the team was slow. It was messy because every ticket had been treated as equally urgent for long enough that "equally urgent" had stopped meaning anything. New bugs got triaged next to eighteen-month-old feature requests next to duplicate reports next to tickets nobody remembered opening. Sprint planning had turned into an argument about which fire to fight first, every two weeks, indefinitely.

The instinct in that situation is usually one of two things: hire more engineers to burn down the pile faster, or propose a platform rewrite so the "real" backlog can start clean. Both are expensive, and neither fixes the actual problem, which was triage, not throughput.

What we did instead

We built a tiered triage system, nothing exotic, just a forced, consistent classification pass on every open ticket, sorted by actual business impact and actual effort, not by how recently or loudly someone had asked about it. Tickets that were duplicates, stale, or no longer relevant were closed outright, not silently, but with a note explaining why. Tickets that mattered got a tier. Tickets that didn't got archived without guilt.

Most backlog debt isn't a capacity problem. It's a sorting problem that's been avoided for so long it starts to look like a capacity problem.

The forcing function wasn't a tool. It was a standing rule that nothing entered a sprint without a tier, and tiers got reviewed on a fixed cadence instead of reactively. That consistency is what actually moved the needle: within 13 weeks, we'd cleared 42% of the backlog, and sprint throughput was up 20% on the same team, same headcount, same codebase.

Why this is usually skipped

Triage is boring. It doesn't produce a demo, it doesn't look like progress in a sprint review, and it's tempting to skip straight to "let's just build faster." But a team shipping quickly into an untriaged backlog is just generating next quarter's mess at a higher velocity. The unglamorous sorting work is what makes the fast work actually count.

Where this applies beyond one team

The specific tiers used were built for that product and wouldn't transfer as-is. The pattern does transfer: before adding headcount or proposing a rewrite to solve a backlog problem, it's worth asking whether the real issue is capacity at all, or whether it's that nothing has forced a consistent, unemotional sort of what's actually in the pile. Across the engagements we've run, it's the second one far more often than the first.