severity-vs-priority-reference
Pure-reference catalog distinguishing defect severity (impact on the system / user) from defect priority (urgency of fix), each on its own axis. Enumerates the canonical 5-point severity scale (Critical / High / Medium / Low / Trivial) and the 5-point priority scale (Immediate / High / Medium / Low / Deferred), explains why they must be tracked separately (a Critical/Deferred legacy bug exists; a Trivial/Immediate spelling bug on the homepage exists), maps to IEEE 1044-2009 severity classes, and ties to bug-lifecycle-reference state transitions. Use when triaging a defect, configuring a tracker's severity/priority fields, or reviewing whether a bug report assigned them consistently.
severity-vs-priority-reference
Overview
Severity and priority are two independent axes, not synonyms. Every triaged defect must have both, and the combination drives scheduling, escalation, and SLA enforcement.
This skill is a pure reference consumed by bug-report-critic (which rejects reports that conflate the two), the platform-workflow skills, and downstream triage tooling.
When to use
The two axes
Severity scale
Per IEEE 1044-2009 (cite by stable ID; "Standard Classification for Software Anomalies") and ISTQB CTFL syllabus:
| Severity | Definition | Example |
|---|---|---|
| Critical (S1) | System unusable; data loss; security breach; total loss of function. | Production database is corrupted on user signup. |
| High (S2) | Major function broken; significant user impact; no easy workaround. | Checkout fails 30 % of the time; no workaround. |
| Medium (S3) | A function works incorrectly; usable workaround exists; impact bounded. | Date picker shows wrong month abbreviations; users can type the date. |
| Low (S4) | Cosmetic or minor inconvenience; functionality not impaired. | Footer copyright year not updated. |
| Trivial (S5) | Spelling, alignment, polish-level issues. | "Settngs" link misspelled in sidebar. |
Per ISTQB Glossary "severity" entry (glossary.istqb.org): "the degree of impact that a defect has on the development or operation of a component or system."
Priority scale
Per ISTQB Glossary "priority": "the level of (business) importance assigned to an item, e.g., a defect."
| Priority | Definition | Example |
|---|---|---|
| Immediate / Blocker (P1) | Stop the release; halt downstream work until fixed. | Production outage; security incident in progress. |
| High (P2) | Fix in current sprint / before next release. | Customer-reported high-severity bug. |
| Medium (P3) | Fix when capacity permits in coming sprints. | Medium-severity bug with workaround. |
| Low (P4) | Backlog; fix opportunistically. | Low-severity, no customer impact. |
| Deferred (P5) | Won't fix in foreseeable horizon. | Cosmetic in deprecated feature. |
Why they must be separate axes
The "combined severity-priority" scale is a common anti-pattern. Each cell in the 5×5 matrix below represents a real combination:
| P1 Immediate | P2 High | P3 Medium | P4 Low | P5 Deferred | |
|---|---|---|---|---|---|
| S1 Critical | typical | unusual but real | rare | rare | rare |
| S2 High | typical | typical | typical | rare | rare |
| S3 Medium | unusual | typical | typical | typical | unusual |
| S4 Low | unusual | unusual | typical | typical | typical |
| S5 Trivial | unusual (PR demo!) | rare | unusual | typical | typical |
Worked examples that prove the distinction:
Mapping to lifecycle
Severity and priority don't change with state (typically). However:
See bug-lifecycle-reference for the state transitions; this skill defines the orthogonal severity / priority fields.
Common confusions
| Confusion | Reality |
|---|---|
| "Severity = customer impact." | Severity = system function impact. Customer impact informs priority. A bug that breaks an unused admin tool is High severity but Low priority. |
| "Priority always equals severity." | False. The 5×5 matrix has 25 distinct cells, all observed in practice. |
| "Critical defects always get fixed immediately." | False. A Critical defect in a deprecated subsystem may be Deferred. |
| "Cosmetic = Low / Trivial severity always Low priority." | False. Marketing context (S5 / P1 example above) can make trivial severity an immediate priority. |
| "Severity is set by the reporter; priority by the PM." | Convention varies. Best practice: reporter proposes severity; triager confirms severity + assigns priority. |
Configuring a tracker
| Tracker | Severity field | Priority field |
|---|---|---|
| Jira | Custom field (often Severity with select-list) | Built-in Priority field |
| Linear | Custom field (Severity), no first-class | Built-in Priority field (Urgent / High / Medium / Low / No priority) |
| GitHub Issues | Labels (severity:critical etc.) | Labels (priority:p1 etc.) + Projects status |
| Azure DevOps | Built-in Severity (1 - Critical / 2 - High / 3 - Medium / 4 - Low) | Built-in Priority (1 / 2 / 3 / 4) |
| Bugzilla | Built-in Severity + Priority | Same |
The platform-workflow skills (jira-bug-workflow-runner, linear-bug-workflow-runner, github-issues-bug-workflow) each cover the platform-specific configuration.
Anti-patterns
| Anti-pattern | Why it fails | Fix |
|---|---|---|
| Single combined field | Loses information; everyone fights about whether to bump severity to escalate or vice versa | Two fields, explicit per defect |
| Default both fields to "Medium" | Triagers don't engage with the distinction | Require both fields explicitly on transition from New → Open |
| Auto-equate severity with priority | "S1 must be P1" - disallows S1/P5 deferred legacy bugs | Allow both axes independently |
| Severity is purely subjective | Variability across reporters; metrics unreliable | Use the IEEE 1044 examples + team-calibrated rubric |
| Priority changes weekly without reason | Metrics chaos; no accountability | Log priority changes with rationale |
| Critical defects always escalated to release manager | Floods the escalation channel | Use severity and priority for escalation rules |