Defect severity and priority
Also called: severity vs priority, bug severity, severity levels
Severity is how badly a defect hurts the user’s journey. Priority is how soon the team will fix it. They are set by different people.
Severity describes impact: can the user finish the journey, is there a workaround, is data wrong, is compliance touched. The tester proposes it from evidence. Priority describes order: when the fix is scheduled against everything else. Product sets it.
The two disagree all the time, and they should. A severe defect in a feature three customers use may wait. A cosmetic defect on the sign-up page may be fixed today.
Severity scales fail when they have more levels than people can remember. I use four levels defined by questions about the journey, with examples taken from the team’s own tickets, so that a new developer can classify sensibly without a training session.
Template: Defect severity scale template