Defect triage: severity, priority and who decides

Defect triage is the regular decision about which defects get worked on, in what order, by whom. The word comes from emergency medicine, where the same problem exists: more patients than hands, and a need to sort by consequence rather than by arrival.

Two attributes drive it, and they are constantly confused.

Severity is how bad the defect is in itself. Data loss is severe. A misaligned icon is not. It is a technical judgement, and the tester usually sets it.

Priority is when it gets fixed relative to everything else. That is a business judgement, and product usually sets it.

A defect can be high severity and low priority. A crash in a feature two customers use might wait. A cosmetic typo on the pricing page might be fixed this morning, because it is on the pricing page.

The terms you will hear

• Severity. The technical impact of the defect. Typically critical, high, medium, low.
• Priority. The order in which it will be addressed. Often P1 to P4, or now, next, later, never.
• Triage. The meeting or process where both are agreed and owners are assigned.
• Defect lifecycle. The states a defect moves through: new, triaged, in progress, fixed, verified, closed.
• Known issue. A defect accepted and documented rather than fixed for this release.
• Won't fix. A closed defect nobody intends to address. An honest state, and better than pretending.
• SLA. An agreed response time per severity, common in support-facing teams.

Why it matters

Because without a shared definition, severity becomes a negotiation about tone of voice.

For example, a tester marks a defect critical because a customer might see a wrong balance. An engineer downgrades it because the underlying data is fine. Both are reasoning honestly from different definitions, and the meeting turns into a debate about the word instead of the risk.

Writing the levels down once removes that entirely. It takes twenty minutes and it is the single highest-value thing you can do to a bug tracker.

How a triage meeting should run

1. Keep it short and regular. Fifteen to thirty minutes, twice a week, with the same three people: tester, tech lead, product.
2. Only look at new and disputed defects. Everything else is already decided.
3. Read severity from the report, not from memory. A report with steps, evidence and a frequency line makes this fast, which is the argument for reports that get fixed.
4. Set severity first, then priority. Keeping them in that order stops the business question contaminating the technical one.
5. Assign an owner and a decision, not a discussion. Fix now, fix next, accept as a known issue, or close as won't fix.
6. Say the release consequence out loud. "This one blocks Thursday" is the sentence that makes triage useful, and it feeds straight into the summary report.
7. Write accepted items into the release note. An accepted defect with a name and a date is a decision. Without them it is an oversight waiting to be found.

A worked severity scale and agenda

For example, here is the scale one small team agreed, plus a real triage from the gift-card release.

Notice WB-1865 and WB-1866. One is accepted with a named person and a date, the other is closed honestly. Neither is left drifting, which is what makes the remaining count mean something.

How to show you know it

• A written severity scale your team agreed. Rare, cheap, and it ends a recurring argument.
• A defect where you argued severity down. It shows you set it from evidence rather than from how much the bug annoyed you.
• An accepted known issue with a name and a date. The paper trail that protects everybody later.
• A backlog you cleaned. "We closed 96 defects nobody would ever fix, with reasons." Then your open count means something, which is what makes the numbers worth reporting.