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.

• Severity measures how badly the defect breaks the system / user when triggered. It's an objective property of the defect.
• Priority measures how urgently the fix must land. It's a scheduling decision, influenced by severity but also by business context (customer commitments, regulatory deadlines, release timing).

This skill is a pure reference consumed by defect-report review (which rejects reports that conflate the two), the platform-workflow skills, and downstream triage tooling.

When to use

• Reviewing whether a bug report's severity + priority are both set and consistent with the defect description.
• Configuring a tracker's severity / priority field options.
• Coaching a tester / triager on the distinction.

How to use

1. Read the defect and decide what function it breaks and how badly; pick a severity (S1-S5) from the severity scale anchors.
2. Separately weigh how urgently the fix must land given business context; pick a priority (P1-P5) from the priority scale.
3. Locate the pair in the 5x5 matrix; if the cell is "rare" or "unusual", record an explicit rationale for the combination.
4. Confirm you did not collapse the axes (do not force P1 just because severity is S1) - the two values are independent.
5. Set the tracker's severity and priority fields per the configuring-a-tracker table for your platform.
6. On any later re-triage (state change), keep severity fixed and revisit priority only.
7. Log every priority change with its rationale.

The two axes

Severity scale

Per IEEE 1044-2009 (cite by stable ID; "Standard Classification for Software Anomalies") and ISTQB CTFL syllabus:

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."

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:

Worked examples that prove the distinction:

• S1 / P5 (Critical / Deferred) - Real defect: a security vulnerability in a legacy system scheduled for deprecation next quarter. Severity is objectively Critical (the bug, if triggered, breaks the system) but priority is Deferred (the whole subsystem is being removed; patching it is wasteful). Action: track + monitor; if exploited before deprecation, re-prioritise.

• S5 / P1 (Trivial / Immediate) - Real defect: a typo on the hero copy of the marketing site that says "Bweekly" instead of "Biweekly," and the CEO just shared the page on LinkedIn. Severity is objectively Trivial (no function broken) but priority is Immediate (PR / brand impact).

• S2 / P3 (High / Medium) - Real defect: checkout intermittently fails for a specific bank's cards (3 % of transactions), workaround = use a different card. Severity is High (major function impaired), priority is Medium (workaround exists + no SLA breach yet).

• S3 / P1 (Medium / Immediate) - Real defect: a regression surfaced 4 hours before a marketing email lands that mentions the feature. Severity is Medium (function works in 90 % of cases) but priority is Immediate (marketing dependency).

Worked example

A CSV export appends one trailing blank column for every user. The export still succeeds and every data value is correct.

1. Severity: the function works and data is intact; the defect is a cosmetic formatting flaw -> S4 Low (functionality not impaired).
2. Priority: a major enterprise customer's ingestion pipeline breaks on the extra column, and their renewal is next week -> P2 High (business commitment, near-term deadline).
3. Matrix check: the pair is S4 / P2 - an "unusual" cell, so log the rationale (customer renewal dependency).
4. Set Jira Severity = Low, Priority = High; do not bump severity to justify the urgency.

Result: the fix is scheduled in the current sprint despite Low severity, driven entirely by the High priority - a clean demonstration that the two axes move independently.

Mapping to lifecycle

Severity and priority don't change with state (typically). However:

• Re-triage at state change: when a deferred defect resurfaces as a production failure, severity is unchanged but priority jumps.
• Severity escalation rules: many trackers auto-bump priority if severity is S1/S2. The platform-workflow skills configure these.
• SLA driven by priority: P1 = e.g., 4-hour response, P2 = 1 business day, P3 = 1 week. SLAs are tracker config, not severity-derived.

See bug-lifecycle-reference for the state transitions; this skill defines the orthogonal severity / priority fields.

Common confusions

Configuring a tracker

The platform-workflow skills (jira-bug-workflow-runner, linear-bug-workflow-runner, github-issues-bug-workflow) each cover the platform-specific configuration.

Anti-patterns

Limitations

• Subjectivity remains. Severity has objective anchors (S1 = data loss, S5 = cosmetic) but boundary cases (S2 vs S3 with a workaround) require judgment. Reviewer disagreement is normal.
• Priority is a moving target. Business context shifts weekly; a P3 today may be P1 next sprint after a customer escalation.
• Severity classes vary by tracker. Some use 4-point scales (Bugzilla), some 5 (Azure DevOps), some define their own. The team must pick one and document it.
• No automation can fully classify severity. AI classifiers can suggest, but the final call needs a human in the loop.

References

• ISTQB Glossary - "severity" and "priority" entries - glossary.istqb.org.
• IEEE 1044-2009 "Standard Classification for Software Anomalies" - cite by stable ID; canonical severity classification.
• ISO/IEC/IEEE 29119-3:2021 §6 anomaly-report fields - cite by stable ID.
• Atlassian "Configure priority levels" - Jira priority docs.
• Linear "Priority levels" - Linear priority docs.
• GitHub Issues - labels + Projects status documentation.
• Sibling references: bug-lifecycle-reference, defect-taxonomy-istqb.