Severity vs Priority

## Two different questions about the same defect Every defect record answers two questions that people constantly conflate. The first is **how bad is the broken behaviour** — a property of the product, observable by anyone who can reproduce the failure. The second is **how soon should we fix it** — a property of the business and the plan, not of the code. Severity is the first answer; priority is the second. They live in separate fields because they are separate facts, produced by different evidence and owned by different people. ## The severity scale Severity is usually a small ordinal scale with published definitions. A common five-step version: - **Blocker** — work cannot continue: the product will not start, or a whole flow is impassable, or testing itself is stopped. - **Critical** — a core function fails or data is lost or corrupted, with no workaround. - **Major** — a significant function behaves wrongly, but a workaround exists or part of the flow survives. - **Minor** — behaviour deviates in a way that annoys rather than blocks; the user still completes the task. - **Trivial** — cosmetic or textual; nothing functional deviates. The exact labels vary between teams, and that is fine as long as the definitions are written down and applied consistently. What matters is that severity is argued from the observed failure: what broke, whether the data survived, whether the user can still finish. Two testers looking at the same reproduction should reach roughly the same severity. If they routinely do not, the scale definitions are too vague, not the testers. ## The priority ordering Priority is an ordering over the fix queue. It answers: of everything we could fix in the next unit of work, where does this sit? Because it is an ordering, it is inherently relative and inherently unstable — the same defect can be top of the queue in the week before a release and mid-queue the week after, without one line of the product changing. Priority takes severity as an **input**, but also takes reach (how many users or how much traffic touches the path), frequency (how often the failure fires when the path is taken), whether a workaround exists and how tolerable it is, contractual or regulatory deadlines, and what else is competing for the same engineer. ## Independence: why both fields are needed The clean way to see the independence is the two-by-two grid. High severity with high priority is the obvious case — the crash on the main flow. Low severity with low priority is the obvious other case — a misaligned label on an internal admin screen. The interesting corners are the mixed ones, and their existence is exactly why the two axes cannot be collapsed. A trivial rendering flaw on the first screen of a signup flow may be high priority because every prospective customer sees it. A crash that destroys in-memory state may be low priority because it is reachable only through an internal path behind a flag that has never been enabled outside a test environment. If a team keeps only one field, it silently picks one meaning and loses the other. Keep only severity and the queue is ordered by technical drama, so the flashy crash nobody reaches jumps ahead of the small thing costing sign-ups. Keep only priority and the historical record loses the technical facts: six months later nobody can tell whether the deferred defect corrupted data or misaligned a button, so the deferral cannot be re-judged. ## Who owns which The usual convention is that the **reporter proposes severity** and **product, or a triage forum, sets priority**. The reporter has the evidence for severity: they saw the failure, they know whether the data came back, they know whether a workaround exists. They do not have the evidence for priority: release commitments, contract terms, which customer is on which build, what else the team owes this quarter. Note the asymmetry in verbs — the reporter *proposes* severity, and triage may adjust it once the true impact is understood, but the adjustment must be argued from the behaviour, not from a wish to move the defect up or down the queue. ## Using the two fields honestly In practice the discipline is simple. Set severity from what you observed, in the vocabulary of the written scale, and support it with the reproduction. Say what you believe the priority should be, and support that with reach, frequency and workaround rather than with adjectives. Then accept that the priority decision is not yours to make. The most common failure is inflating severity to win a priority argument: it works once, it corrupts every severity-based measure the team has, and after two or three rounds the severity field stops carrying information at all.