Bug Severity vs Priority: A Decision Framework That Ends the Argument

The single rule that ends every triage argument

Severity describes the bug; priority describes the schedule. Stop debating them in the same sentence. A CRITICAL bug can be P3 if it only affects a deprecated feature. A LOW-severity bug can be P0 if it ships in a CEO demo at 2pm. Separating the axes ends 80% of triage disagreements.

Severity: what is broken

ISTQB defines severity as "the degree of impact that a defect has on the development or operation of a component or system." It is a technical assessment, independent of business value or user count. Use four labels with concrete behavioral definitions — not numeric scales, which drift.

The four severity labels and what they mean:

• CRITICAL — Data loss, security exposure, or the whole application is down for a class of users (all paying customers, all mobile users, all users in EU). Examples: customer data deleted on save, auth bypass, checkout returns 500 for every user.
• HIGH — A major feature is broken with no workaround. Most users encountering it can't complete their primary task. Examples: a key form fails to submit, search returns no results, billing page won't load.
• MEDIUM — A feature is broken or behaves wrong, but a reasonable workaround exists. Examples: dashboard chart loads slowly, a non-critical setting doesn't save, the menu collapses on a rare device.
• LOW — Cosmetic issues, typos, minor inconveniences. Examples: misaligned text, color contrast on a non-critical button, wrong icon on a tooltip.

Note: severity is independent of how many users see it. A bug that affects 1% of users badly is still CRITICAL if it deletes data. A bug that affects 100% of users mildly is MEDIUM at best.

Priority: when (and whether) we fix it

Priority is a scheduling decision made during triage. Unlike severity, it incorporates business context: who's affected, what release we're shipping, what the team's other commitments are. Use P0/P1/P2/P3 (not numeric scales). Priorities can change as conditions change; severity rarely does.

The four priority labels:

• P0 — Stop the world. Drop everything currently in progress. Fix is shipped within hours, typically same day. Reserve for true emergencies.
• P1 — This sprint. The bug is on the active sprint board; an owner is assigned; it ships in the next release.
• P2 — This quarter. Sized into a future sprint within ~12 weeks. Owner not assigned yet; rough estimate exists.
• P3 — Backlog. Acknowledged but not scheduled. May get fixed opportunistically when an engineer is in the area; may never get fixed if priorities shift.

A useful test: if you can't say "we will fix this by date X," it's P3. P0 through P2 each carry a commitment; P3 explicitly does not.

The 4×4 matrix in practice

The full severity × priority matrix has 16 cells. Most teams settle into 5-6 of them; the rest are theoretically possible but rare. Use the matrix as a sanity check: if your assigned priority looks wrong for the severity, ask why — the answer usually surfaces a constraint that wasn't on the table.

When severity and priority diverge

Three concrete examples where severity and priority diverge — and the reasoning is sound. These cases are why we keep the axes separate: collapsing them forces false trade-offs and obscures the actual decision.

LOW severity, P0 priority — the CEO demo. A typo in the headline of the page the CEO is about to demo at a board meeting. Cosmetic, but the visibility is asymmetric — fix it now even though it's objectively unimportant.

CRITICAL severity, P3 priority — the deprecated feature. A bug that causes data loss in a feature you announced you're shutting down next month. Severity is high; priority is low because the fix isn't worth the effort against the planned removal.

HIGH severity, P2 priority — the long-tail browser. A major feature breaks on a niche browser used by 0.1% of your traffic. Severity is HIGH (the feature is broken), priority is P2 (it can wait until the next quarterly release).

How to handle the disagreement in triage

When triage gets stuck on a bug, the disagreement is usually about priority, not severity. Split the conversation into two steps: agree on severity first (a technical assessment), then negotiate priority (a business decision). Most arguments resolve in the second step once everyone agrees on the first.

The 4-step protocol:

1. State the severity first. "I see this as HIGH because the form is broken and there's no workaround."
2. Get explicit agreement on severity before discussing priority. Three options for the team to pick: agree, raise (CRITICAL), or lower (MEDIUM).
3. Then set priority with business context. Who's affected? Is there a release pressure? What's the cost of waiting?
4. Document the reasoning in the ticket. Six months from now, "why was this P2?" should be answerable from the ticket alone.

Common mistakes

• Conflating the axes. "It's a P1 because it's serious" — that's two thoughts in one. Disentangle them.
• Using a numeric scale. A "Severity 3" means nothing without a definition. "MEDIUM = workaround exists" is portable.
• Letting priority bleed back into severity. Just because you decided not to fix it doesn't change what's broken.
• No SLA per priority. Without time commitments, P0/P1/P2 are just labels. Define what each one means in calendar time.
• Severity inflation. When every bug is HIGH, none are.

How BugMojo models this

The BugMojo data model treats priority as a polymorphic field on the Issue entity with CRITICAL/HIGH/MEDIUM/LOW/NONE values. Severity isn't a separate field — it's expected to be encoded in the ticket description or labels. We considered making severity a first-class field and decided against it: small teams over-thought the distinction; large teams added it via labels naturally. The bias is to not force structure that teams don't actually use.

Next steps

• Adopt the 4-level severity scale verbatim. Don't customize until you've used it for 3 months.
• Add the priority SLAs to your team's runbook: "P0 fix shipped in 4 hours. P1 in 1 sprint. P2 in 1 quarter."
• Train new reporters on severity definitions, not priority — priority is a triage-team responsibility.

Try BugMojo free to capture bug reports with priority baked into the capture flow — no separate triage spreadsheet required.

Frequently asked questions

What is the difference between bug severity and priority?

Who sets severity and who sets priority?

Should we use a numeric scale or a label?

What about urgency?

When should a bug be CRITICAL severity?

Sources

1. ISTQB Glossary — Severity definition — ISTQB (2024)
2. How to Report Bugs Effectively — Simon Tatham (2025)
3. Atlassian Jira priority documentation — Atlassian (2025)