Severity and priority are often conflated, although they answer different questions. Severity describes the impact of a problem on the system or user; priority describes how urgently the team should address it.
What is severity?
Severity expresses a defect's technical or user impact: how much it disrupts functionality, data, security, availability, or a core flow.
What is priority?
Priority expresses the business urgency of a fix: whether it is needed now, before release, in the next sprint, or can wait.
Why they do not always align
- →A severe defect can have low priority if it affects a rare or temporarily disabled scenario.
- →A minor visual defect can have high priority if it appears on the main screen before an important demonstration or marketing campaign.
How to discuss them effectively
- →Assess severity through its impact on the system, data, and users.
- →Discuss priority in the context of business needs, timelines, the release, the audience, and team capacity.
- →Keep the concepts distinct: "I think this matters" does not establish high severity.
Strong QA can justify severity and priority rather than merely assign them. This reduces unproductive triage arguments and helps the team make decisions faster.