Not every bug deserves to block a release. Here's how high-performing QA teams decide what to fix first — and how to get developers to agree.
At some point in every sprint, you hit a moment where there are more bugs than time. Something has to wait. The question is: what?
Most teams answer this question badly — either by gut feel, by whoever shouts loudest, or by the order bugs happened to arrive. The result is a backlog where a cosmetic alignment issue blocks a release while a data loss bug sits unassigned for two weeks.
Good bug prioritization isn't complicated, but it does require a shared framework that everyone — QA, developers, and product — agrees on before the pressure hits.
Severity vs. priority: the distinction that matters
The first thing to get straight is the difference between severity and priority. They're not the same thing, and confusing them is the root cause of most prioritization arguments.
- Severity describes how bad the bug is technically — does it crash the app, corrupt data, or just misalign a label?
- Priority describes how urgently it needs to be fixed — relative to everything else on the board right now.
A bug can be high severity but low priority. A crash in a feature used by 0.1% of users on a deprecated browser matters technically but may not need to block your next release. Conversely, a low-severity bug — say, a misleading label on your checkout button — might be top priority because it's directly hurting conversion.
Severity is a property of the bug itself. Priority is a property of the bug relative to your current context.
A four-level severity scale that actually works
Most teams use four severity levels. The key is having specific, agreed definitions so that testers apply them consistently — not based on how they're feeling that day.
- 1.Critical — The application crashes, data is lost or corrupted, or a core user flow is completely broken. No workaround exists. This stops a release.
- 2.High — Major functionality is broken, but the app still runs. A workaround may exist but is not acceptable for production. Needs fixing before release in most cases.
- 3.Medium — A feature doesn't work as expected, but the impact is limited in scope or a reasonable workaround exists. Targeted for the current or next sprint.
- 4.Low — Cosmetic issues, minor copy errors, small UI inconsistencies. Tracked but not release-blocking. Fixed when bandwidth allows.
Write these definitions down somewhere your whole team can see them. The moment they exist only in someone's head, they stop being a shared framework and become a source of disagreement.
The four factors that determine priority
Once severity is established, priority is a judgment call — but a structured one. Four factors should inform it:
1. User impact
How many users hit this bug, and how often? A bug on your login page affects every user on every visit. A bug in an advanced settings panel affects a small percentage of power users occasionally. The wider and more frequent the impact, the higher the priority.
2. Business impact
Does the bug affect revenue, legal compliance, or reputation? A broken payment flow is a priority-one issue regardless of its technical severity. A broken admin export that only three people use internally is not. Map bugs to the business outcomes they affect.
3. Reproducibility
A bug that happens 100% of the time is more urgent than one that appears intermittently. Intermittent bugs are also harder to fix, which affects scheduling decisions even when priority is high.
4. Fix complexity
A medium-priority bug that takes 15 minutes to fix should often jump the queue ahead of a high-priority bug that requires a multi-day refactor. Getting easy wins resolved keeps the backlog moving and maintains momentum.
When to escalate immediately
Not everything goes through the normal triage process. Certain bugs should trigger an immediate escalation regardless of where you are in the sprint:
- Data loss or corruption of any kind — user data, financial records, or any persisted state
- Security vulnerabilities — exposed credentials, broken authentication, unprotected endpoints
- Crashes on the main user path — login, signup, checkout, core product flow
- Bugs that have already reached production and are affecting live users
Agree on an escalation path before you need it. Who gets notified? On which channel? Within what timeframe? Having that written down means a critical bug at 5pm on a Friday doesn't turn into a four-hour conference call to figure out who's responsible.
Getting developers to agree with your prioritization
The biggest failure mode in bug prioritization isn't bad judgment — it's a QA team that sets priorities in isolation and then fights with developers about them. The fix is collaborative triage.
A short triage session — 15 minutes at the start of each sprint, or a standing async process using your task board — where QA and at least one developer review new bugs together almost always produces better outcomes than either side deciding alone. QA knows what's broken. Developers know what's expensive to fix. Neither side has the full picture on their own.
When both sides have agreed on a priority, it also stops the common pattern of developers quietly deprioritising bugs they find inconvenient to fix. The shared decision creates shared accountability.
What a good bug report does for prioritization
One underappreciated factor in prioritization quality is report quality. It's very hard to assign the right priority to a bug that says "button doesn't work" with no URL, no environment info, and no screenshot. You can't assess user impact, reproducibility, or fix complexity without that context.
When bug reports arrive with the full context automatically captured — URL, browser, OS, viewport, screenshot, DOM element — prioritization becomes a five-second decision rather than a five-minute investigation. The information needed to assess severity and priority is already in the report.
The test: would a new team member agree?
A useful sanity check for your prioritization framework: if a new QA engineer joined your team tomorrow and read your definitions and your current backlog, would they agree with how everything is labelled? If the answer is yes, your framework is working. If the answer is "they'd need a lot of context to understand why things are prioritized this way," your framework is living in people's heads rather than in a shared system.
The goal isn't perfect prioritization — that doesn't exist. The goal is a process that's consistent, transparent, and fast enough that bugs get to the right developer at the right time without anyone spending half their day arguing about what matters.