Severity vs priority: why a critical bug can wait

Severity measures how much damage a defect does when it happens. Priority measures how soon it makes sense to fix it. They are two different questions: one is answered by the system (how serious the technical failure is), the other by the business (how urgent the repair is). Blurring them is why so many teams fix things that are ugly but harmless before things that are quiet but dangerous.

The typical scene is this. A tester finds a button that renders badly on a screen almost nobody visits: it looks awful, but no one gets stuck on it. At the same time there is a tax calculation that is off by a few cents at checkout, something you barely notice, yet it costs the company real money every day. The first one shouts louder. The second one does more harm. Deciding which goes first is, exactly, the work of separating severity from priority.

01 · the two questionsSeverity is how much it hurts, priority is when you fix it

The standard testing vocabulary defines them separately on purpose. Severity is the degree of impact that a defect has on the development or operation of a component or system [1]. It is an almost objective property of the failure: does it bring the application down, corrupt data, or merely misalign an icon? Priority, in contrast, is the level of business importance assigned to resolving it: how high up the fix queue you place it [1].

The distinction matters because the two do not move together. A defect can be very severe and low priority, or barely severe and top priority. That independence is exactly what makes it useful: it forces you to think about technical impact and commercial urgency as two axes, not as a single one.

Severity is set by the system. Priority is set by the business. When you mix them, you fix by volume of complaints, not by real damage.

Who assigns each one also differs. Severity is proposed by whoever understands the technical behavior of the defect: the tester or the developer who reproduces it. Priority is decided by whoever understands the cost of leaving it loose: the product owner, the lead, or the business itself. When a single person sets both "by eye", they almost always collapse the two into one blurry number, and that is where the mess begins.

02 · the four quadrantsWhy a critical bug can sometimes wait

Because severity and priority are independent axes, they cross into four combinations. Each one calls for a different decision, and the two uncomfortable corners (high-low and low-high) are the ones most often misread.

High severity, high priority. The easy case. The app crashes in the payment flow for every user. It hurts a lot and it has to be fixed now. Nobody argues about this quadrant.

High severity, low priority. This is where the "critical bug that can wait" lives. Imagine a failure that corrupts data, but only fires on an operating system version used by 0.1 % of your users, in a feature that ships next month. Technically it is serious. Commercially, today, it is not urgent: you can schedule it without panic. High severity, low priority.

Low severity, high priority. The mirror image. A spelling mistake in your company's name on the home page, or a key client's logo placed wrong right before a demo. The system works perfectly: minimal severity. But the embarrassment or the commercial risk is enormous, so it gets fixed within the hour. Maximum priority.

Low severity, low priority. The bottom of the queue. A two-pixel margin on an internal screen that three people ever see. It gets logged, scheduled for someday, and sometimes never touched. And that is fine.

03 · how to decideSort by data, not by whoever shouts loudest

The real problem is not understanding the difference in theory, it is failing to apply it under pressure. When a noisy customer's report arrives through a direct channel, it tends to jump the queue, even if its defect is minor. And when a serious failure lives in a corner nobody reports, it sinks into the backlog, even though one day it will blow up. Deciding "by whoever shouts loudest" is exactly the bias the matrix exists to correct.

To sort priority by data, instead of by volume of complaints, three concrete questions help almost every time.

How many people does it affect? A failure that touches every user weighs more than one that touches a very rare case, even if the second is technically more severe. Reach pushes priority upward.

Is there a way around it? If a simple workaround exists (another path in the interface, a manual step), the urgency drops, even though the severity stays intact. A defect with no escape escalates; one with an emergency exit can wait its turn.

What does it cost to leave it loose one more day? Lost money, legal risk, reputation, a breach of contract. That daily cost, not the ugliness of the symptom, is what should push priority. A defect that bleeds money every hour rises even if you can barely see it.

A mature board does not ask "what is the ugliest?". It asks "what costs us the most to leave loose today?".

At Qirava we see the same pattern over and over: teams that separate these two axes well argue less and ship with a clear conscience, because their fix queue is auditable. Anyone can see why one defect goes before another, and that reason is not "someone with a loud voice asked for it", but a fact: reach, available workaround, cost per day. Severity is documented, priority is justified, and the decision stops being a fight of opinions.

So the next time someone says "it is critical, we have to fix it now", stop and separate the two questions. Is it critical because it hurts a lot, or because it is urgent? Sometimes they are the same thing. Often they are not. And knowing when they are not is the difference between a team that puts out small fires and one that protects the house.