Stop Triage Theatre: Fix Bugs by Severity, Not Priority

Who This Is For

You're a developer, a lead, or a QA person who's tired of the bug tracker being a graveyard of good intentions. You've read the advice about writing perfect bug reports and following the lifecycle to the letter. But deep down, you know the real problem isn't the report—it's the workflow. So let's cut the crap.

This is for anyone who wants to fix bugs faster without turning your process into a bureaucratic nightmare. I'm going to walk you through a blunt, practical approach that separates the wheat from the chaff—and gets you shipping fixes that matter.

1. Severity Over Priority – The Only Triage That Matters

Here's the contrarian take: stop obsessing over priority. Priority is just how urgent a bug feels; severity is how much it actually breaks things (Atlassian, issue priority vs severity). In my experience, the moment you let priority drive the queue, you end up with the loudest bug getting fixed while the system quietly rots.

Instead, triage by severity first. That means a bug that crashes the app or corrupts data—call it Fatal or Blocker—gets fixed immediately, regardless of who's screaming. A minor UI glitch, no matter how many times the CEO hits it, can wait. You can always adjust priority later to reflect business context, but severity is the ground truth.

Here's what can go wrong: if you ignore severity and just go by priority, you'll end up with a backlog of "High" priority bugs that are actually cosmetic, while a "Low" priority bug with a severity of Blocker sits unfixed because no one tagged it right. I've seen it happen. Don't let it happen to you.

2. A Workflow That Doesn't Suck

You don't need a fifteen-stage workflow. You need one that mirrors reality. The classic lifecycle—New, Assigned, In Progress, Fixed, Pending Retest, Retest, Verified, Closed—is fine, but it's overkill for most teams (Atlassian, bug life cycle). Simplify.

Here's the minimal workflow that works: Open, In Progress, In Review, Done, Closed. Add a Triage step if you're fancy (Atlassian, issue priority vs severity). The key is to have a clear definition of done and to move bugs through quickly.

• Open: Bug is reported and triaged.
• In Progress: Someone is actively working on it.
• In Review: The fix is done, but needs a second look.
• Done: The fix is merged and deployed.
• Closed: Verified and confirmed.

Don't get stuck in the weeds. The goal is to get bugs from Open to Closed as fast as possible without breaking things. Remember, the largest study on the delayed issue effect found no evidence that fixing issues later costs more effort (arXiv, Menzies et al. 2016). So don't panic about every hour a bug sits in the backlog—but do keep the workflow moving.

3. Write Reports That Actually Help

A good bug report is a gift to your future self. It should include reproduction steps, expected vs actual behavior, severity and priority, environment details, and visual proof (Atlassian, bug life cycle). But here's the thing: you don't need to write a novel. Just be precise.

For accessibility bugs, make sure you're testing against a specific WCAG version. WCAG 2.2 has 13 guidelines under four principles, and it's backwards compatible with 2.1 and 2.0 (W3C WAI, WCAG 2 Overview). So if you say "WCAG AA failure," specify which version you're testing against. That's the difference between a fix that takes a day and one that takes a week.

4. Track the Right Metrics and Stop Chasing Ghosts

You've probably heard that fixing bugs late costs more. But the data says otherwise. The delayed issue effect isn't a universal truth—it occurs only in certain kinds of projects (arXiv, Menzies et al. 2016). So don't build your entire process around slashing cycle time. Instead, track the metrics that matter: defect rejection ratio and defect leakage ratio (Atlassian, bug life cycle). These tell you if your team is writing junk reports and if bugs are slipping into production.

And please, don't fall for the myth that exhaustive testing is necessary. NIST research shows that practically 100% of software failures are triggered by no more than six interacting variables, and 70–95% are triggered by just two (NIST, combination testing news release). So use combinatorial testing tools like ACTS to test smart, not exhaustive. Your workflow will thank you.

The Takeaway

Stop treating bug tracking like a religious ritual. Triage by severity, use a simple workflow, write reports that are actually useful, and measure what matters. That's it. The rest is noise. Your job is to fix bugs that affect users, not to stroke the ego of the loudest stakeholder. Do that, and your tracker will be a tool for shipping, not a museum of missed opportunities.

Sources

• Atlassian (bug life cycle) - https://www.atlassian.com/software/jira/guides/bug-tracking/bug-life-cycle
• Atlassian (issue priority vs severity) - https://www.atlassian.com/software/jira/guides/issues/priorities
• arXiv (Menzies et al. 2016, delayed issue effect) - https://arxiv.org/abs/1609.04886
• NIST (2010 combination testing news release) - https://www.nist.gov/news-events/news/2010/11/updated-nist-software-uses-combination-testing-catch-bugs-fast-and-easy
• W3C WAI (WCAG 2 Overview) - https://www.w3.org/WAI/standards-guidelines/wcag/