Table Of Contents
Every team has this argument, when a simple agreement can clear most of it up.
A bug gets logged and QA flags it as critical. Product marks the Priority field Low and bumps it down the backlog. QA pushes back – “but it’s critical.” Product comes back with “but it’s not affecting that many users right now.” Both are right, but they are having two completely different conversations using the same word.
This argument can eat up precious sprint planning time. Not because the bug is hard, not because the call is hard, but because the team has not separated two very different ideas that should never have been represented by one field.
Severity Is Not Priority
Severity = “how bad is it when it happens and what’s the blast radius.”
Priority = “how urgently should we fix it before it becomes a bigger issue.”
Those are two different questions, and the answers are produced by different people for different reasons, in most cases.
Severity is technical. It comes from QA, from dev, from anyone with hands on the actual issue. It’s about impact at the point of failure. Does the system crash? Is data getting corrupted? Does the user lose their session?
Priority is business. It comes from product, from leadership, from whoever understands the customer impact, the timing, and the cost of fixing versus shipping. Priority is contextual, given the same bug can be top priority for one team and low priority for another. It all depends on what is being delivered, and where it fits in the release window.
If you confuse them, you’ll get an argument that could go on to become a huge thorn in the team’s side. But if you separate them, you can have a much more civil conversation and remove a potential blocker from your working day.
Awkward Combinations
Once you stop conflating the two, the awkward combinations simply stop.
Critical severity, low priority is a real thing I have dealt with many times, and it’s fine. A data corruption bug in a feature flagged off for everyone but a 10-person beta test. Severity says it’s serious, which it is. Priority says it’s not blocking the release. In this scenario, both can be true.
Low severity, high priority is also a real thing. A typo on the landing page during a marketing launch. Severity says it’s nothing – a typo, the colour is wrong, zero impact on functionality. Priority says fix it now, because the brand cost during a launch is high. Once again, both can be true.
The argument gets fobbed off because the team is trying to argue both fields with one word. Separation keeps things clear.
Where the Conversation Actually Belongs
QA owns severity. Product owns priority. That is the cleanest split, and it prevents most arguments before they start.
QA can speak to the technical impact, on behalf of the Dev team for example, or get Dev involved. They were the ones in the system when the bug hit, they know what state was lost, what data was affected, what the workaround looks like. They logged a “big beautiful” ticket for all to fully understand. Severity is their assessment.
Product can speak to the business impact. They know what the customer is doing this week, what the release schedule looks like, what is queued up next. Priority is their call.
When QA says “this is critical” and product says “this is low priority,” neither is wrong. They are answering two different questions. The team needs to make sure both questions are asked, and the answers should be represented via two separate fields.
The Bug Template Fix
The simplest fix: two fields, both required, owned by different people.
A Severity field that QA fills in.
Critical, Major, Moderate, Minor (or Critical, High, Medium, Low – pick a scheme and stick with it). Each level has a clear definition, which I’ll get into shortly.
A Priority field that product fills in.
P1, P2, P3, P4. No rules attached. Priority is contextual and it can change many times a week. The important part is that QA does not set it. Product can change priority every sprint (or sooner as the team work through planned items), and QA does not have to renegotiate severity every time.
Two fields should result in one conversation. The argument moves from “is this critical or not” to “we agree it’s high severity, what do we want to do about it this sprint, if anything.”
I have seen teams resist this countless times. Please don’t let anyone tell you different. The real issues happen when a ticket appears and the team waste time arguing because the field is doing double duty, confusing everyone. Splitting it saves time and forces the team to articulate what they mean by “critical” and “not urgent”. It avoids that wonderful saying, “we’re having a violent agreement”.
The Matrix in Practice
Once you split severity and priority into two fields, you can put them on a matrix and turn the combination into an action. This is what most teams I have worked with end up with, give or take minor details.
| Severity → | S1 – Critical | S2 – Major | S3 – Moderate | S4 – Minor | |
|---|---|---|---|---|---|
| Priority ↓ | P1 – Critical | Fix Immediately | Fix Immediately | Fix This Sprint | Schedule Soon |
| P2 – High | Fix Immediately | Fix This Sprint | Fix This Sprint | Schedule Soon | |
| P3 – Medium | Fix This Sprint | Fix This Sprint | Schedule Soon | Backlog | |
| P4 – Low | Schedule Soon | Schedule Soon | Backlog | Backlog |
The matrix turns “what severity, what priority” into “what do we do about it.” Once a bug lands in a cell, that action is the response.
Severity Levels
Severity describes the impact when the bug occurs. QA owns this assessment.
| Level | Name | Description |
|---|---|---|
| S1 | Critical | System crash, data loss, security breach, all users impacted. No workaround. |
| S2 | Major | Core feature broken, significant impact to most users. Workaround is difficult. |
| S3 | Moderate | Feature partially broken, some users impacted. Workaround exists. |
| S4 | Minor | Cosmetic issue, minor inconvenience. Little to no impact. |
Your team may prefer different words, just be careful not to confuse them with what Priority is using. Ultimately however, the names are not the point, the definitions are.
Priority Levels
Priority describes how urgently to fix. Product owns this call.
| Level | Name | Description |
|---|---|---|
| P1 | Critical | Must be fixed immediately. Blocking release or live outage. |
| P2 | High | Must be fixed in the current sprint or cycle. |
| P3 | Medium | Should be fixed in the next sprint or cycle. |
| P4 | Low | Fix when time permits. Not time-sensitive. |
The descriptions are deliberately about timing, not impact. That’s the whole point. If a priority reads like a severity description, the framework has regressed.
From Matrix to SLA
The matrix is also where most teams I have worked with derive their SLAs. Usually with input from Support and the business. Once each cell has a default action, the action implies a fix window.
Fix Immediately means hours, not days. Fix This Sprint means within the current cycle. Schedule Soon means within the next sprint or two. Backlog means triaged and reviewed at a regular cadence, not promised by a date.
Putting that in writing turns the matrix from a sorting tool into a service commitment. Teams that operate under contractual obligations – regulated industries, B2B platforms, anything with a support contract – usually need this anyway. The matrix gives them a clean structure to build on.
If you do not have an SLA today, the cells of the matrix are a fair starting point. If you do, the concept shouldn’t be foreign to you.
Everyone Has an Opinion
The clean split – QA owns severity, product owns priority – sounds good on paper. In practice, the matrix does not stop people lobbying for what they want.
Support pushes for higher priority because they are the ones taking the calls. They hear user impact and it can look bigger from the support seat than it does from the dev seat.
Sales pushes because a key account called and the conversation got uncomfortable. Client pressure is a very real daily driver.
Delivery pushes back because every “fix immediately” is a “stop everything we were going to do.” Which is a fair point given project promises already made.
If you have a ticketing system for clients, they also want a say because they are paying for the product. They often have one, as most systems let them set severity and/or priority when they log a defect. The client’s input is useful but as with any SLA, it’s likely not final.
And then there is the email from the CEO or any C-Suite member for that matter, things get mighty uncomfortable on these occasions.
Even with the matrix (SLA) in place, you may still have discussions about where things really sit. They may get heated and the matrix may get overridden from time to time, that is just business, a little politics too maybe.
The matrix as the business agrees (especially if tied to SLA’s), gives everyone a defensible position to clients and other stakeholders of your business. As long as any override is explicit and the reason is in writing, you’ll be fine, remember always CYA (cover your ass).
What This Fixes
Once severity and priority are separated, conversations should get easier. The argument may never go away entirely, but it becomes less personal, and much shorter.
Triage gets faster. A Critical Severity/Low Priority bug is parked with full context about why it’s parked. Nobody has to defend “leaving a critical bug open” because the priority field tells the rest of the story.
Defect management becomes a breeze, or at the very least, less of a minefield requiring constant justification.
Exceptions to the Defaults
Two default fields is not a magic fix. There are still situations where it gets messy.
Anything marked “critical” in regulated industries, often requires fix-or-document within a fixed window regardless of business priority. In that case the priority field is constrained by the severity field, and that is fine – the rules just need to be explicit.
A high-severity security issue cannot be parked at low priority forever, even if the business case isn’t there yet. There is usually a policy that says “anything Critical or High security severity must be addressed within X days.” That constraint sits above the priority field, and the team needs to know it exists.
The Take
Severity is impact. Priority is timing. Different questions, owned by different people, answered with different information. Combine those fields and you get the same pointless argument every sprint. Separate them and the team gets to talk about the work instead of the labels.
The fix is structurally minor – two fields, two owners, two scales. The harder part is cultural. Allowing QA to stop overselling critical bugs, and letting product stop having to defend leaving them parked. Both jobs get easier when the field stops doing double duty.
Stop arguing about whether something is critical or a priority. Create a matrix of default labels and actions, even for your own internal SLA’s. You’ll have much better conversations going forward.
A Note on Context
Every business and every project is different. What works in one place won’t work in another, and that’s the point.
Nothing here is meant to be a step-by-step prescription. It’s guidance, drawn from my own experiences, and deliberately kept general to avoid pointing fingers anywhere.
Take what’s useful, ignore what isn’t, and adapt it to your own context. Or as Joe Colantonio always says: “Test everything and keep the good.”
