The one-line difference
Severity = how bad is the technical impact? (determined by the QA/engineering team)
Priority = how urgently does this need to be fixed? (determined by the business/product team)
These are independent dimensions. A bug can be technically severe but low business priority, or technically minor but extremely high business priority. Confusing them causes misallocation of engineering effort.
The 4 severity levels
- Critical (S1) — System crash, data loss, security vulnerability, complete feature failure with no workaround
- High (S2) — Major feature broken, significant user impact, workaround is difficult or unavailable
- Medium (S3) — Feature partially broken, workaround exists, limited user impact
- Low (S4) — Minor issue, cosmetic, very limited user impact
The 4 priority levels
- P1 (Urgent) — Fix immediately, drop everything
- P2 (High) — Fix in the current sprint
- P3 (Medium) — Fix in the next sprint
- P4 (Low) — Fix when convenient, or close as Won't Fix
Real examples of the disconnect
| Bug | Severity | Priority | Why |
|---|---|---|---|
| Payment fails for users paying in USD (affects 0.1% of Indian customers) | S1 Critical | P3 Medium | Technically severe but USD customers are rare in this market |
| Company logo misaligned on the login page | S4 Low | P1 Urgent | Cosmetic, but CEO demo is tomorrow morning |
| Export CSV button missing for free tier users | S2 High | P4 Low | Feature wasn't supposed to exist for free tier anyway |
| Homepage loads in 8 seconds on mobile | S3 Medium | P1 Urgent | 60% of traffic is mobile; Google penalises slow pages; conversion is dropping |
💡 Who sets what: QA engineers set severity — they're closest to the technical impact. Product managers or business owners set priority — they know the business context. When there's a conflict, both should discuss it, not override each other unilaterally.
Why teams collapse severity and priority into one field
It's simpler. One dropdown instead of two. But the simplification creates confusion: "Critical" in a single-field system means something different to the QA engineer who logged it vs the product manager who's planning the sprint. The QA engineer meant "this is technically broken badly." The PM heard "fix this before anything else."
Keeping them separate avoids this miscommunication entirely. Each person fills in their dimension; together they give a complete picture.
How to combine them for sprint planning
In sprint planning, look at the combined matrix:
- S1 + P1 — Drop everything. This is in today's deploy.
- S1 + P2 — In this sprint, scheduled early in the week.
- S2 + P1 — Also in today's deploy, right after the S1+P1 issues.
- S3 + P3 and below — Goes in the backlog, sorted by combined score.
- S4 + P4 — Consider closing as Won't Fix. These often aren't worth the opportunity cost.
Setting up severity and priority in Resolvo
Resolvo's issue tracker supports both fields independently. When creating a bug report:
- The reporter (or QA engineer) sets Severity based on technical impact
- The product manager or team lead sets Priority based on business urgency
- SLA alerts trigger based on Priority (P1 gets alerted fastest)
- Sprint planning views show both fields side-by-side
Track bugs with both severity and priority in Resolvo
Two-field classification, SLA by priority, sprint assignment. Free to start.
Start Free →