Table Of Contents
A few years back I opened a bug backlog that had ~400 open defects sitting in it. The team had been carrying it long before I started. Nobody had logged a duplicate on purpose, and nobody had left a bug open out of spite. It just happened, the way these things do, slowly, one ticket at a time. But throw in a UI/UX upgrade and things get out of hand quickly.
Looking at that list, I could not have told you how many of those bugs still reproduced. Some referenced screens that no longer existed. A few described behaviour in a feature that had been rebuilt twice since the ticket was raised. And a bunch were almost certainly duplicates, logged three times by three different people who never checked.
So I did what we all do. Started at the top and worked my way down. Open the ticket, review it, check it out directly. Does it still fail? Does the ticket still makes sense? Is this the same thing as that one I saw earlier? It’s slow and thankless work, and most of the time the honest answer is “not sure, let me go look again.”
That is defect management when nobody has been doing it. And the thing that is supposed to stop a backlog ever getting to that state, the quiet promise holding the whole thing together, the SLA. So let’s talk about both, because they are the same conversation seen from different ends.
Triage Is the Whole Game
Triage is the engine room. Remove the tooling and the ceremony and it’s just a regular conversation where someone looks at the incoming defects and decides three things:
- is this a real issue?
- what’s the impact, and priority?
- who owns it and where does it fit?
I’ve written about severity vs priority on its own, so I won’t repeat myself here. The short version is that severity is “impact” and priority is “timing”, they’re owned by different people, and confusing the two is how you lose hours to an argument nobody wins. Triage is where those labels get assigned, along with everything else the ticket needs before it’s actionable (Definition of Ready, you could say).
Triage on a beat, weekly or fortnightly, and the backlog remains as a list you can trust. Skip it for a few months and you get my 400 “mystery” tickets. The backlog wasn’t a tooling failure, it was a process failure.
There’s a textbook way of splitting triage into five jobs, and it’s actually a useful lens for seeing where the work goes:
- Capture the defect from wherever it came in
- Check whether it’s a duplicate
- Classify what kind of thing it is
- Score how severe it is
- Route it to whoever should deal with it next
Most teams do all five in one meeting and call the lot “triage”, which is fine. But naming the steps matters, because two of those five is where a lot of pain lives.
Deduplication and the Walking Dead
Duplicates first.
The studies I’ve seen online put them somewhere in the 10 to 30 percent range of all tickets, which lines up with what I’ve seen. Confirming a duplicate is genuinely tedious work. Review both the new and the old one, compare the steps, then decide whether they’re the same root cause or two symptoms that just happen to look alike.
Then there’s the “walking dead”.
Bugs that have been open so long the system has moved on without them. This is the bit that ate most of my time on that backlog. Is this still a thing, it’s using the old UI that no longer exists? The feature’s been rebuilt, so does the bug even apply anymore? The uncomfortable truth is that a lot of those old tickets are simply clutter, and clutter should be purged, not preserved out of guilt.
What people forget is fixing a stale bug is often riskier than the bug itself. You’re going back into code written by someone who may have left, re-familiarising yourself with decisions nobody documented, and every change is a fresh chance to break something else.
Where AI Can Help
This is the part that would have saved me days, weeks even.
As of 2026, AI triage isn’t a science project anymore. It’s shipped natively into the tools most of us already use. Sentry has Seer for error tracking, Linear has triage built into its higher tiers, GitHub runs it through the Copilot SDK, and Jira has it via Rovo. They all do a similar job. The system reads an incoming report, compares it to everything that came before, scores, flags, and routes it, all before a human opens the ticket.
Notice what that list is. It’s the two jobs nobody wants, deduplication, and routine classification. The slow, tedious part of triage is precisely the part a model is now “good enough” to take off your hands.
It still needs verification, unless you can build in some confidence trigger. Anything above the threshold is good to move, anything less and it requires a human to intervene.
The caveat, and it’s the same one I keep seeing with AI. It’s good at the routine and the obvious, but it’s no good at judgement. No model can tell you whether a six-month-old bug still matters to the business this quarter, because the model never has all the context. Not everything makes it into a ticket, so a human is still required.
Schillers and vendors will quote you big numbers, ~90 percent faster triage, accuracy in the high nineties. Treat those as vendor claims and move on, focus on the value in removing a chunk of the boring stuff. And one practical note, if your tickets carry customer data, think where that is going before you pipe it all through external AI.
The Backlog Is Not a Strategy
Honestly, the backlog is where bugs go to be forgotten. I’m just saying it because it needs saying out loud.
I’ve watched a team declare what you could call bug bankruptcy. The backlog had grown past the point of usefulness, so leadership made the call to delete the lot and start fresh, on the promise that the new bugs would be triaged properly. And you can guess how that went.
The counter-move that’s had a lot of airtime is the zero bug policy. Fix it or close it, and never let a permanent backlog accumulate. Bugs take priority over new work until the count is back to zero.
When you accept a bug onto the backlog, with support telling the customer “we’ll get to it as soon as we can”, quietly knowing full well it’s unlikely, you haven’t managed a defect. You’ve lied to a customer, and that should sit badly with everyone, SLA or not.
I’ll be honest though, the zero bug policy is a bit extreme for most businesses. Which tends to fight directly with the severity and priority model that most teams actually need for their SLA’s. So here’s a pragmatic middle ground I’d argue for. Have a “Won’t Fix” status and use it honestly. Age bugs out with a written rule, something like “not prioritised after six sprints becomes a candidate for Won’t Fix.”
You don’t need zero bugs. You need a backlog small enough that every bug in it is one you actually intend to fix. Everything else gets closed with a written reason. A backlog list of things you’ll never do is not a plan, it’s a graveyard you’re paying to maintain.
SLAs: The Promise Behind the Work
An SLA is the moment you turn “we’ll fix it fast” into a number both sides have agreed to. It takes a vague promise and makes it something you can be contractually held to.
The bit people mess up is that there are two clocks, not one. Response time is how long before you acknowledge the issue and start work. Resolution time is how long before it’s actually fixed and service is restored. They’re usually tiered by priority, so a release-blocker gets a tighter clock than something no-one is waiting for.
In all seriousness, Response SLAs are easy to promise. Resolution SLAs are risky, and anyone who’s run a support team knows why. How can you honestly promise a four hour fix when the root cause might be a four hour investigation on its own? The mature answer is to promise a fast response with a workaround, and treat the permanent resolution as a separate commitment.
I have seen this subject discussed and manipulated by people who would be great lawyers!
A starting point could look something like this. Given the numbers depend entirely on what your business can actually deliver, adjust to suit.
| Priority | What it means | Response | Resolution or workaround |
|---|---|---|---|
| P1 – Critical | Must be fixed now, blocking release or live outage | 30 minutes | Workaround in 4 hours, permanent fix to follow |
| P2 – High | Fix this sprint or cycle, significant business impact | 2 hours | Workaround same day, fix in the next release |
| P3 – Medium | Fix in an upcoming sprint, no urgent business pressure | 1 business day | Addressed in an upcoming release |
| P4 – Low | Fix when time permits, not time-sensitive | Logged and acknowledged | When capacity allows |
Two things actually let you hit a resolution SLA, and neither of them is heroics.
Prevention, so you’re catching defects before they ship and the clock never starts. And escalation, so when the clock is running there’s a clear, agreed path for quick action. A resolution SLA with no escalation path is a promise with no engine behind it.
A small nuance that saves a lot of panic. SLA clocks usually runs on business hours. A P3 raised at 4pm on a Friday and sorted by 9am Monday might be one working hour against the SLA, not the whole weekend. Check how the clock is defined and agreed before you panic, or celebrate.
Agile, Waterfall, Same Questions
The mechanics differ depending on how your team works. The questions underneath don’t.
In an agile team it stays continuous and light. Triage runs on rhythm, defects get fixed in sprint where you can manage it, anything live in production jumps the queue, and when a feature ships and bugs spike, retro’s to fix the cause.
At the regulated end of town, it can be much more formal. You get a defect review board or a change control board, with the right people in the room. You get phase-gate exit criteria, where the high-severity defects have to be cleared before go-live, no exceptions. And the formal version of “we’re not fixing this now” is reclassifying the defect as a change request, which moves it out of the bug column and into scope and budget where it belongs. The SLAs at that end are explicit and contractual, because someone up high has signed their name against them.
The labels and the meetings change between agile and waterfall, but the decision being made is identical.
The Take
Triage is the engine. Run it on a regular basis or you’ll pay for it later with a backlog you can’t trust, full of tickets nobody can vouch for anymore.
Duplicates and stale bugs are the tax you pay for not running it, and they’re exactly the work AI is now “good enough” to take off your hands, just keep the judgement calls for a human.
The backlog is not a strategy. Fix it or close it, and don’t leave bugs sitting open that you have no real intention of fixing, because that’s just lying to everyone. Keep the list short enough that everything on it matters.
The SLA is the promise behind all of it, so promise what you can actually keep. A fast response beats a fix time you’ll miss. Prevention and escalation are how you keep the fix times you do commit to. Agile or waterfall, the questions never change.
Keep the list short, keep it honest, and fix the things you said you’d fix. The rest is just noise you’re paying to maintain.
A Note on Context
Every business and every project is different. What works in one place won’t work in another, and that’s the point.
Nothing here is meant to be a step-by-step prescription. It’s guidance, drawn from my own experiences, and deliberately kept general to avoid pointing fingers anywhere.
Take what’s useful, ignore what isn’t, and adapt it to your own context. Or as Joe Colantonio always says: “Test everything and keep the good.”
