Severity, Priority and What Gets Fixed First
Severity is how bad it is; priority is when we deal with it. Why the two come apart, who decides each, and how to argue for a fix with evidence instead of feelings.
Severity is how bad it is; priority is when we deal with it. Why the two come apart, who decides each, and how to argue for a fix with evidence instead of feelings.
You filed a report on Monday and marked it High: the CSV export is completely broken. By Friday it is untouched. Meanwhile a misspelled company name in the site header — five characters, functionally nothing — was fixed within the hour.
That looks like somebody is not paying attention. Usually nobody has made a mistake at all. It is the difference between two words people use as though they were one.
By the end of this lesson you will know exactly what severity and priority each measure, why they legitimately come apart, who decides each, and how to argue for a fix with evidence instead of insistence.
How bad is this behaviour?
A property of the defect itself: what it does, what it breaks, what it could cost. It does not move because the release plan moved.
A measurement. Yours to judge.
When do we deal with it?
A decision about what to do next, given the schedule, who is affected, what else is in flight, and what the business needs this month.
A decision. Usually not yours to make.
Nobody argues about whether data loss is severe. Whether it gets fixed before Thursday's release is a judgement somebody has to make with information you do not all have.
Scales vary by organisation. The shape is nearly always this, and the width below is roughly how many of each you should expect to file.
Data loss, a security breach, nothing works at all. Every payment failing.
A core function is broken and there is no way round it. The reset email never arrives.
Broken, but the user can still get the job done another way. Bulk edit fails; editing one at a time works.
Wrong, and nobody is blocked. The sort order is odd.
Appearance only. A button two pixels out of line.
Two rules make the scale mean something.
"No workaround" is what separates High from Medium. If the user can still get the job done another way, however annoyingly, it is Medium. That single question resolves most severity arguments.
Data loss and security are Critical regardless of how rare. A bug that corrupts one record in ten thousand is Critical, because the consequence is unbounded and undetected corruption spreads. Rarity is a priority input, not a severity input.
All four combinations happen constantly, and two of them are the ones that cause arguments.
The export fails completely — for a feature two customers use, neither of whom has run one in six months.
Checkout fails for a quarter of users. Nobody needs convincing about this one.
A tooltip is truncated at one screen size. Never getting done is a legitimate outcome.
The company name is misspelled in the header. Functionally nothing — and it is on every page during a launch week.
The two off-diagonal boxes are where the friction lives, and understanding them is what removes it.
A tester who insists that high severity must mean high priority is arguing against information they do not have. A product owner who downgrades the severity because they do not want to fix it yet is corrupting the record — the defect is still exactly as bad as it is, whatever the plan says.
If you want to influence priority, these are the inputs that matter — and none of them is severity alone:
How many users are affected, and which ones. Ten users is different from ten thousand, and the largest customer is different from an inactive trial account.
How often it happens. Every time, or once in a thousand? A rare bug in a common flow can outrank a certain bug in a rare one.
Whether there is a workaround, and how bad it is. "Do it one at a time" is survivable for ten records and not for ten thousand.
What it costs while unfixed. Support tickets, refunds, manual data correction, reputational damage, regulatory exposure.
How risky the fix is. A one-line change goes in before a release; a change to the payment flow does not, three days before a launch.
What else is competing. A fix always displaces something.
Notice that four of those six are things you can supply and a product owner cannot easily discover. That is where your influence lives.
Bad — insistence, with severity as the argument:
Good — the priority inputs, supplied:
The first message restates the severity, which was already in the ticket, and adds pressure. Pressure is the weakest available argument: it gives the person deciding nothing new, and it makes the next conversation adversarial.
The second supplies exactly the inputs the decision needs, in numbers, and explicitly leaves the decision where it belongs. It is much more likely to move the ticket, and it is why the last line matters — it signals that you understand the trade-off rather than merely wanting your bug fixed.
Triage is the recurring meeting where new defects get their priority set. The term is borrowed from emergency medicine, and the analogy is apt: limited capacity, so sort by what happens if you wait.
A functioning triage does four things per defect, quickly:
Your job in that meeting is to be the person who can answer questions about impact without going away to look. Which is a preparation task: knowing how many users, how often, and what the workaround costs, before you are asked.
"Will not fix" is a legitimate outcome, and worth defending rather than resenting. A defect nobody hits, in a feature being retired next quarter, is not worth a developer's week. What matters is that the decision is recorded with a reason, so the same report does not get filed and re-triaged three more times.
Most priority disagreements are not worth your energy. Two are.
A Critical treated as routine. Data loss and security exposure are different in kind: they compound, they are often undetectable after the fact, and they can carry legal obligations. If a defect corrupts data or exposes it, say plainly that it is in that category, say why, and escalate if it is not treated accordingly. This is the one place where being insistent is correct.
A severity downgraded to justify a priority. Marking a data-loss bug as Medium because it is not going to be fixed this month is a record that will mislead everyone who reads it later. Argue for the record: "leave it High and set the priority to backlog" costs nothing and keeps both fields honest.
Everything else — a High that waits, a Low that gets fixed first, a bug in the backlog for a year — is the system working. Your value is in the quality of the information, not in winning the scheduling argument.
Defects are found, reported and prioritised. The next lesson is about what happens after they are fixed: regression testing, why suites grow without limit, and why every bug should leave a test behind — which is the mechanism that stops the same defect being reported twice.
Before that, take three open defects you know about and write down their severity and their priority separately, with a reason for each. Where the two differ, check whether you can explain why. That explanation is the skill this lesson is about.
This is High severity and it has been open for two weeks. It
really needs to be prioritised — the export feature is
completely broken.On BUG-412 (export returns an empty file):
- 214 accounts used export in the last 30 days; 41 used it more
than once a week.
- It fails every time for files over 5,000 rows, which is 60% of
our exports.
- The workaround is exporting in pages of 1,000, which for a
typical customer is 12 manual exports.
- Six support tickets since the 3rd, two from accounts on
renewal this quarter.
Happy for it to wait if something bigger is in flight — flagging
because the support load is growing rather than steady.1. Is it real, and is it reproducible?
No repro -> back to the reporter for more, not into the backlog.
2. Is it a duplicate?
Link it and close it.
3. What is its severity?
Sanity-check what the reporter set. Adjust with a reason.
4. What is its priority?
Fix now / this sprint / backlog / will not fix.# Two different questions
severity how bad is the behaviour? a MEASUREMENT — usually yours
priority when do we deal with it? a DECISION — usually not yours
# A severity scale
critical data loss, security breach, nothing works
high a core function broken, NO workaround
medium broken, but there is a workaround
low wrong, not blocking
cosmetic appearance only
# Two rules that settle most arguments
# "is there a workaround?" separates High from Medium
# data loss and security are Critical however rare — rarity is a
# PRIORITY input, not a severity one
# All four combinations are legitimate
high severity, low priority broken export, two dormant customers
low severity, high priority company name misspelled in the header
high, high checkout fails for 25% of users
low, low truncated tooltip; may never be fixed
# What actually drives priority — supply these
how many users, and which ones
how often it happens
whether there is a workaround, and what it costs to use
what it costs while unfixed: tickets, refunds, manual correction
how risky the FIX is, this close to a release
what it would displace
# Arguing well
# restating the severity adds nothing — it was already in the ticket
# numbers beat adjectives: 214 accounts, 6 tickets, 60% of exports
# leave the decision where it belongs, explicitly
# Triage, per defect
1. real and reproducible? no repro -> back to the reporter
2. duplicate? link and close
3. severity sanity-check it, adjust with a reason
4. priority now / this sprint / backlog / will not fix
# "will not fix" is legitimate — record the reason
# The two arguments worth having
# a Critical (data or security) being treated as routine — escalate
# a severity downgraded to justify a priority — keep the record honest