Defect severity scale template

A severity scale is only useful if people can apply it from memory in release week. This one has four levels, each defined by a question about the user’s journey and tied to a consequence for the release.

The examples are the part that makes it work. Replace the placeholders with real tickets from your own backlog, one or two per level, and review them with Product and Engineering.

Defect severity scale template
DEFECT SEVERITY SCALE

Severity is about impact on the user's journey. Priority (when it is fixed) is set by Product.

BLOCKER
  Test:    a core journey cannot be completed and there is no workaround;
           or wrong data is saved or sent; or compliance is breached.
  Release: stop, or the business accepts a named risk in writing.
  Our examples: <ticket>, <ticket>

CRITICAL
  Test:    a core journey fails for some users; or a lesser journey fails for everyone;
           or the only workaround is one users will not find.
  Release: fix before ship unless Product explicitly defers.
  Our examples: <ticket>, <ticket>

MAJOR
  Test:    the journey completes, with friction or a workaround users can manage.
  Release: scheduled, and listed as open in the readiness note.
  Our examples: <ticket>, <ticket>

MINOR
  Test:    no effect on completing any journey.
  Release: fixed when the area is next touched.
  Our examples: <ticket>, <ticket>

Questions to ask, in order
  1. Can the user complete the journey?
  2. Is there a workaround they would find on their own?
  3. Is any data wrong, lost or exposed?
  4. Is a legal, contractual or compliance commitment affected?

Disagreements: <who can appeal, on what evidence, who decides, within how long>
Core journeys: <the short list this scale refers to>

Free to use and adapt. No sign-up, no attribution needed.

How to use it

  • Agree the list of core journeys first. The scale refers to it in every level.
  • Use examples from your own tickets. One worked example does more than a paragraph of definition.
  • Keep severity steady under release pressure. It describes impact, which does not change because the date is close.
  • Write down how a disagreement is settled before the first one happens.

Terms used here: Defect severity and priority, Defect triage, User journey.