1.4Priority vs Severity: Two Different Dimensions

These are different dimensions that are frequently confused. Severity measures technical impact -- how badly is the system broken? Priority measures business urgency -- how soon must we fix this?

They often align, but not always. Understanding the difference is a mark of professional maturity.

	Low Severity	High Severity
High Priority	CEO's name misspelled on About page	Payment processing crashes for all users
Low Priority	Tooltip misaligned on admin settings page	Data export corrupts records (feature used once per quarter)

The high-priority, low-severity cell is the one that surprises junior engineers. A typo is technically trivial, but if the CEO's name is wrong on the company website, it will be fixed today regardless of its technical severity.

The low-priority, high-severity cell is equally instructive. A data corruption bug is technically severe, but if it affects a feature used once per quarter by one internal user, it may sit in the backlog for months.

Severity Levels

Level	Definition	Example
Critical	System unusable, data loss, security breach	All users cannot log in; credit card numbers exposed
Major	Key feature broken, no workaround	Checkout fails; cannot place orders
Minor	Feature works but with issues, workaround exists	Search results display incorrectly but users can filter manually
Trivial	Cosmetic, typo, minor UI issue	Button misaligned by 2px; typo in footer

Priority Levels

Level	Definition	Response Time
Critical	Fix immediately, all hands on deck	Hours
High	Fix this sprint	Days
Medium	Fix next sprint	1-2 sprints
Low	Fix when convenient	Backlog

Common Mistake: Marking everything as "Critical" priority. When everything is critical, nothing is critical. Developers learn to ignore priority fields when they are consistently inflated. Reserve Critical for genuine system-down, data-loss, or security-breach scenarios. Your team will trust the priority field only if it is used honestly.