Your bug backlog is a list of decisions nobody made

Most teams think their bug backlog is a list of problems. It is not. It is a list of decisions nobody made, and it grows at exactly the rate the organisation avoids making them.

I have looked at a lot of defect backlogs over twenty years. The shape is almost always the same. A few hundred open items. A long tail older than the current product version. Severity fields filled in by whoever raised the bug, priority fields that have not been touched since. A weekly triage meeting where the same items are read aloud, nodded at, and left exactly where they were.

That meeting is not triage. It is a reading group.

Triage is a decision meeting, not a sorting exercise

The word triage comes from emergency medicine, and the original meaning is useful. Triage exists because resources are limited and you must decide who gets treated now, who waits, and who you cannot help. It is uncomfortable by design. Its output is an action for every case.

Bug triage in most software organisations has kept the vocabulary and dropped the discomfort. Items get categorised, labelled and ranked, which feels like progress. But ranking a bug is not deciding about it. A bug ranked "medium" that sits for eighteen months has had exactly one decision made about it: not now. That decision was never stated, never owned, and never revisited.

So the first change I push for is simple. Every triage session must end with each discussed item in one of a small number of states, each of which is a decision:

1. Fix now — it goes into the current iteration, with a named owner.
2. Fix later, with a trigger — not a vague "later", but a condition: the next release of that component, a specific customer milestone, a date. When the trigger arrives, the item comes back automatically.
3. Accept — we know about it, we will not fix it, and someone with the authority to accept the risk has said so. Documented, with the reasoning.
4. Close — not reproducible, not a defect, duplicate, or no longer relevant.
5. Investigate — we do not know enough to decide. Time-boxed, with an owner, and it must come back with one of the four outcomes above.

"Leave it open and see" is not on the list. That is the whole point.

Severity and priority are different questions asked by different people

This is old advice, and it is still the most commonly broken rule I see. Severity describes the technical impact of the defect: what breaks, how badly, for whom. Priority describes the business decision: how soon we are going to act on it.

Severity is an assessment. It should be made by someone who understands the system and the failure. Priority is a decision. It should be made by someone who owns the trade-off between this defect and everything else the team could be doing.

When the same person sets both, usually the reporter, two bad things happen. Reporters inflate severity to get attention, and everything becomes critical. Or reporters set priority to match severity, and the business never actually makes a priority decision at all. Either way, the fields stop carrying information.

The check: pull the distribution of severity across your open defects. If more than a third are marked high or critical, the field is no longer measuring severity. It is measuring frustration.

A backlog that cannot shrink is not being managed

There is a healthy metric hiding in most defect trackers, and it is not the count of open bugs. It is the age distribution, and specifically the share of open defects older than the thing they were reported against.

A bug raised against version 2.3 that is still open when you are shipping 4.1 is almost never a bug anymore. It is either fixed by accident, irrelevant because the feature changed, or an accepted limitation that nobody had the authority or nerve to formally accept. Leaving it open has a cost: it hides the bugs that matter in a pile that does not, and it trains everyone to treat the tracker as an archive rather than a work queue.

I wrote years ago about KPIs, dashboards and metrics, and the principle carries straight over: measure for decisions, not for numbers. "Open defect count" invites gaming — close duplicates aggressively, merge tickets, argue about what counts as a bug. "Age of the oldest undecided defect" points at the thing you can actually fix, which is the decision backlog.

Efficient triage excecuted frequently reduces a cycle time of the fixes and customer responce, we were able to achieve 80% reduction here, imrpving stakeholders relationhips and our teams efficiency.

Who triages matters more than how

Process frameworks for triage are easy to find. What they rarely address is who is in the room, and whether the people in the room can actually decide.

The pattern I see in triage meetings that do not work: testers who found the bugs, developers who might fix them, and nobody who can say "we will not fix this" with the authority to make it stick. The meeting can discuss, but it cannot conclude. So it does not.

A working triage has three roles, even if one person sometimes holds two of them:

• Someone who understands the failure — can reproduce it, explain the impact, and estimate how wide it goes.
• Someone who understands the cost of fixing it — what it touches, what it would displace, how risky the fix is.
• Someone who owns the risk — who can accept, defer or prioritise, and will answer for that choice later.

This is the same structure I insist on for a quality gate: a named owner, a defined input, an explicit pass condition, and a real consequence. A triage decision is a gate. It decides what passes into the product with a known defect, and if nobody owns that outcome, it is a gate that only looks like one.

What changes when defects arrive faster

There is a 2026 wrinkle worth naming. When code is generated faster, defects arrive faster too — and they arrive in a different shape. In my BowSmith work, the defects that mattered most were not crashes. They were plausible-looking behaviours that were subtly wrong, inconsistencies between components that were each fine on their own, and regressions in behaviour no test had ever pinned down.

Those defects are hard to triage, because they rarely look severe on the day they are found. "Two screens handle errors slightly differently" does not feel critical. It becomes critical later, when the inconsistency has been copied into ten more places. Triage that only weighs the immediate impact will consistently under-rank them.

So I have added one question to every triage discussion: is this a one-off, or is it a pattern? A one-off gets fixed on its merits. A pattern gets a root-cause item of its own — a missing convention, an absent contract, a gap in the gate — because fixing instances of a pattern one at a time is how backlogs become permanent.

A smaller, honest backlog

The goal of defect management is not zero bugs. It is a backlog where every item is there on purpose. Where "open" means someone has decided it matters and is waiting for a trigger, and where everything else has been fixed, accepted or closed by someone who can explain why.

That backlog is smaller. It is also more uncomfortable, because accepting a known defect out loud is harder than leaving it open and hoping nobody asks. But that discomfort is the job. Triage was always supposed to feel like a decision.

If you have a backlog you are afraid to open, that is a good topic for a Quality Coffee session. Next up in this run: “Quality engineering doesn't save money. It buys the right to decide.” Where would your current triage meeting land on the five outcomes above?