Severity, Priority, and Triage

A defect corrupts an internal audit-log table in a way nobody reads; a second defect renders the logo wrong on the screen the CEO will demo to a board on Thursday. The tester labels the log corruption severity-critical and the logo severity-low — correct, both are technical judgments. Then she sets the log defect to priority-urgent and the logo to priority-later, and by Thursday the board demo ships with a broken logo. Both labels were defensible and the release was still wrong, because priority is not severity's echo — it is a separate axis that answers a business question.

Severity measures technical impact: how badly the software is broken for users of the affected path. The four-level scale most teams converge on:

Severity is assigned by QA at report time (with triage able to revise), and it is stable: the same technical failure carries the same severity regardless of which customer hits it. The scale earns its keep only when each level has a written definition — teams where 'critical' means 'important to me' produce severity noise that makes every escalation sound identical.

Priority measures business urgency: when this defect should be fixed relative to everything else. It is set by product (often with QA's input), and it legitimately disagrees with severity in both directions. The demo-logo case: low severity, high priority — a trivial defect on a high-stakes screen. The reverse case is just as real: a critical-severity defect in a feature that no customer uses until Q4 ships with a high-severity, low-priority disposition — fix scheduled for the release before launch. Both disagreements are correct decisions, and an org where priority always mirrors severity is either not making priority decisions or not making severity ones.

The two-axis model produces the quadrant behavior triage actually runs on:

Interviewers test this separation constantly, and the canonical prompt is exactly the demo scenario: 'a broken logo before a board demo vs a critical bug in an unused feature — assign severity and priority'. The answer that separates candidates: logo = S4/P1, unused feature = S1/P3, and then the sentence that shows the model is understood — severity drives how thoroughly we test and verify the fix; priority drives when it gets fixed. A third label some trackers add — root-cause area or frequency — is optional; severity and priority are the two every process must keep straight.

Triage is the standing meeting where defects get their priority, target release, and owner — and where conflicting viewpoints (QA says critical, dev says minor, product says irrelevant) get resolved into one decision per defect. Done well it takes 15-25 minutes per day or twice a week; done poorly it becomes a status readout that wastes six people's hour. The structure that keeps it sharp:

Inputs ready before the meeting (2 minutes of hygiene): the new-defect queue since last triage, each report with severity suggested by the reporter and reproduction status; the aging report for stalled items; and the release context (what ships this week — priorities are meaningless without it).

Per-defect decision loop (3-5 minutes each):

1. Read the summary and actual result — if the group cannot state the user impact in one sentence, the defect goes back to the reporter for clarification, not to debate.
2. Confirm or revise severity — QA defends the technical-impact assessment with the scale definitions; the discussion is about facts (is there a workaround? is data at risk?), not adjectives.
3. Set priority and target release — product owns this call, using the business context; the demo-screen and unused-feature cases above play out here.
4. Assign the owner and the next action — a named developer for fix-candidates, a named tester for reproduction attempts, a named person for the requirements question. 'The team will look at it' is how defects die in triage.
5. Disposition the recurring disputants: not-a-defect claims get decided against the spec with a change-request path if the spec itself is wrong; duplicate suspicions get linked live; cannot-reproduce gets a reproduction task with a timebox (spend an hour, then close with the attempt record).

Output — the only artifacts that matter: updated defect records (priority, release, owner fields), the list of items pulled into the current release, escalations raised, and a two-line summary posted where absent people read it. If a triage meeting produces no field updates, it was a status meeting wearing triage's name.

The conflict-resolution skills deserve their own note because they are the human core of the role. When QA and dev disagree on severity, return to the written scale and the facts it cites — 'your workaround takes 20 minutes per case, the scale says Major' converts opinions into a defensible call. When product wants a critical defect deferred, do not fight the priority — require the deferral record (target release, accepted impact, approver — the contract from Defect Lifecycle States) so the decision is visible and owned. And when you are overruled on a judgment you disagree with, state the accepted risk in the triage notes in one sentence; that sentence is your professional insurance and the raw material for the escape-rate analysis that comes later.

Escalation between meetings has its own craft, because the meeting cannot catch everything. Escalate with impact, not volume: 'S1 — checkout returning 500s for saved cards since build 4.12.1; 40 support tickets in 2 hours; affects the top revenue path; needs an out-of-band decision today' beats three exclamation marks. Escalation is a professional claim that the cost of delay exceeds the cost of interrupting someone — and like every claim, it is only as strong as the data attached to it. The metrics that tell you whether triage and escalation are actually working are the subject of the phase's final topic, Defect Metrics and Stakeholder Reporting.

Two months after adopting a severity scale, the dashboard shows 34% of defects filed as Critical — the same share as Minor — and nobody escalates anymore because escalation is constant. This is severity inflation, the most common scale failure, and it has a companion pathology: priority capture, where whatever the loudest stakeholder wants becomes P1 regardless of impact. Both destroy the information the scales exist to carry. Calibration is the maintenance work that keeps the labels meaningful.

Inflation happens for three reasons, each with a fix. Reporters pad severity to get attention (fix: triage revises downward publicly, and the scale definitions make revision routine rather than punitive — a reporter whose S1s get corrected learns the scale in a week). Stakeholders learn that S1 is the price of entry to the current release (fix: product sets priority, so urgency does not need severity smuggling — the demo case above is exactly why the two axes exist). And scales without definitions drift (fix: re-anchor on concrete tests — 'does it lose data? is there a workaround? how many users hit it?' — and re-calibrate the open backlog once per quarter, a 60-minute session where a sample of open defects gets re-scored against the definitions).

Tracking the calibration numerically turns opinions into a reviewable signal:

Notice the triage-change-rate signal specifically: a healthy 10-30% revision rate means the scale is being applied, while both extremes are pathologies — zero revision means nobody is actually judging, and 80% revision means the definitions never made it into practice.

The deeper professional point, and the one that closes this topic: severity and priority are communication compression. An S1/P1 label exists so that a stakeholder who reads nothing else knows the shape of the day. Every inflated label devalues the currency for everyone — which is why the tester who calmly downgrades her own S1 to S2 at triage, citing the definitions, is doing more for the team's escalation signal than the one who fights to keep every headline. In interviews, expect a scenario on exactly this: 'how do you handle severity inflation?' Answer with the three causes, the calibration signals (share S1, triage revision rate), and the stance that revising severities is routine quality work on the team's shared language, not a defeat for the reporter.

Priority capture deserves one companion ritual: the monthly priority audit. Export the month's P1 list and ask, per item, which business event justified the urgency — a launch, a campaign, a contract commitment. Items whose justification is 'the VP asked in the meeting' are data: they show where the priority channel is bypassed, and the fix is a conversation with product about the escalation path, not a fight over individual tickets. Calibrated scales compound: after two quarters of honest revision and audit, the team's S1/P1 labels become trustworthy at a glance, and the daily escalation noise that once filled the inbox disappears into recorded decisions.