Stop Treating Every Bug Like a Crisis: A Triage Workflow That Works

I have a contrarian claim: the biggest problem with your bug tracking isn't that you're not fixing bugs fast enough. It's that you're tracking too many bugs in the first place, and treating every single one as if it deserves a developer's attention this sprint. The result is a backlog that looks like a hoarder's garage, and a team that feels perpetually behind. I've seen it in every organization I've worked with, and I'm convinced the fix is not more process, but less tolerance for noise.

But isn't the delayed-issue effect real?

You've heard the rule of thumb: a bug found in production costs 100 times more to fix than one caught in requirements. It's repeated in every software engineering course, and it's used to justify heavyweight upfront reviews and gates. But the largest study yet published on the delayed issue effect — 171 software projects from 2006–2014 — found no evidence that issues resolved in a later phase cost consistently or substantially more effort than issues resolved soon after introduction (arXiv). The study concludes the rule of thumb is not a global truism; it appears intermittently only in certain kinds of projects. So the next time someone tells you to add another approval gate to prevent a late bug, ask them for the data from your projects, not a 1970s paper. I'm not saying late bugs are free, but the fear of them often leads to over-engineering the process.

What's the simplest workflow that actually works?

A simple, effective bug workflow is Open → In Progress → In Review → Done → Closed, optionally with a Triage step (Atlassian). That's it. You don't need fifteen states. The Triage step is where the magic happens: a quick daily or weekly session where a small group (a lead, a QA, a product person) looks at every new bug and decides: fix now, defer, mark duplicate, or reject. This is the single highest-leverage practice I've adopted. Without triage, your tracker becomes a write-only database. With triage, you keep the signal high and the noise low.

Priority and severity: why do we keep confusing them?

Because they sound similar. Priority measures how urgent a bug is to fix; severity measures how much it affects system functionality or user experience (Atlassian). A typo on the homepage might be low severity but high priority if it's the CEO's name. A crash in a rarely used report might be high severity but low priority. I've seen teams spend hours arguing about whether something is a P1 or P2 when the real question is: does this need to be fixed before the next release? If yes, it's high priority. If no, it's not. Severity is a property of the bug; priority is a business decision. Keep them separate, and don't let severity dictate priority.

Do we really need all those extra states like 'Reopened' and 'Deferred'?

Yes, but only a few. Common alternative states include Rejected, Duplicate, Deferred, Reopened, Not a Bug, and Non-Reproducible (Atlassian). I use Rejected, Duplicate, and Deferred religiously. Reopened is a necessary evil — if a fix doesn't work, it goes back to the developer with a note. But 'Not a Bug' and 'Non-Reproducible' are often just excuses to avoid investigation. I'd rather see a bug stay open with a comment 'needs more info' than be closed as non-reproducible. The latter hides problems.

What about security bugs? Don't they need a different process?

Absolutely. Security vulnerabilities follow a separate tracking lifecycle: the NVD enriches every CVE published to the CVE List by aggregating data from the description, supplied references, and other public information (NVD). But for your internal tracking, you should still use the same tracker, just with a separate workflow. The key difference is prioritization: CISA maintains the Known Exploited Vulnerabilities (KEV) catalog as the authoritative source of vulnerabilities that have been exploited in the wild, and directs organizations to use it as an input to their vulnerability management prioritization framework (CISA). In practice, that means if a CVE in your stack appears in KEV, it jumps to the top of your list, regardless of CVSS score. I've seen teams ignore a medium-severity CVE that was actively exploited because their policy said 'critical only'. That's a mistake.

How do we stop bugs from piling up?

First, accept that you will never fix all bugs. Second, set a WIP limit for bugs in progress — no more than two per developer. Third, hold a weekly bug review where you close at least 20% of open bugs as 'won't fix' or 'deferred'. This sounds harsh, but it forces you to confront the fact that most bugs are not worth fixing. The 2002 RTI study prepared for NIST estimated the national annual cost of an inadequate software-testing infrastructure at $22.2 to $59.5 billion, with over half borne by users (NIST). That's a lot of waste, but it doesn't mean every bug is a crisis. It means we need better triage, not more testing.

What I'd actually do

If I were running a team today, I'd implement a three-state workflow: Open, In Progress, Done. No 'In Review' unless you have a dedicated QA. I'd have a 15-minute daily triage where we assign priority and severity, and immediately close anything that's not worth fixing. I'd track two metrics: defect rejection ratio (rejected defects divided by total reported times 100) and defect leakage ratio (production defects divided by total found times 100) (Atlassian). If rejection ratio is below 10%, we're not being ruthless enough. If leakage ratio is above 20%, we're not testing enough. And I'd stop worrying about the delayed-issue effect. The data says it's not a universal truth. Focus on fast feedback loops, automated tests, and a culture that celebrates closing bugs as much as fixing them.

Sources

• Atlassian - https://www.atlassian.com/software/jira/guides/issues/priorities
• NVD - https://nvd.nist.gov/general
• CISA - https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• arXiv - https://arxiv.org/abs/1609.04886
• NIST - https://www.nist.gov/system/files/documents/director/planning/report02-3.pdf