What Is a Bug, Really? Severity vs. Priority Explained

Contributor
Feb 23
4 min read

Two arguments happen on every software team, over and over. The first: "Is this a bug or not?" The second: "Okay, it's a bug — but do we have to fix it now?" Both arguments go in circles when people don't share a clear definition of what a bug is and a clean way to decide what gets fixed first.

There's a simple framework that settles both. Once a team uses it, these debates get dramatically shorter. Here it is.

What actually counts as a bug

A bug is software behaving differently from how it's supposed to behave. That's it. The key phrase is "supposed to" — a bug is a gap between intended behavior and actual behavior.

This definition does important work, because a lot of things that get called bugs aren't:

The login button is green and you think it should be blue → if the design says green, not a bug. That's a preference.
The feature works exactly as specified, but the spec was a bad idea → not a bug, it's a design problem or a feature request.
You enter a valid email and the app rejects it → bug. It's supposed to accept valid emails and it didn't.

Why be strict about this? Because bugs and feature requests are handled completely differently. A bug is a broken promise — the software said it would do something and didn't, so it gets fixed. A feature request is a new promise — someone wants the software to do something new, which gets prioritized against other new work. Calling a feature request a "bug" to jump the queue is one of the oldest moves in software, and it muddies everyone's planning.

When in doubt, ask: "What was this supposed to do?" If you can point to a spec, an acceptance criterion, or a reasonable expectation that was violated, it's a bug. If you're really saying "I'd prefer it worked differently," it's a request.

The two questions that sort every bug

Once you agree something is a bug, the next fight is what to do about it. This is where two words get confused constantly — and separating them is the whole trick.

Severity: how bad is it? This is technical. How much does the bug break? A crash that loses data is high severity. A misaligned icon is low severity. Severity is about the damage.

Priority: how soon should we fix it? This is a business decision. Given everything else we could do, where does this sit in the queue? Priority is about the urgency.

The insight that makes this powerful: severity and priority are independent. A bug can be any combination of the two, and the interesting cases are the mismatches:

High severity, low priority — the app crashes, but only in a rarely-used admin screen that three internal users touch. Genuinely broken, but not urgent. Fix it, just not today.
Low severity, high priority — a typo in your company name on the homepage. Nothing is technically "broken." But every visitor sees it and it looks unprofessional. Trivial severity, drop-everything priority.
High severity, high priority — checkout fails for all users. Both bad and urgent. This is the 2 a.m. page.
Low severity, low priority — a tooltip is slightly off-center on one browser. Log it, fix it whenever.

If your team only tracks one axis, you get bad decisions. Rank purely by severity and you'll spend a sprint on a scary-sounding crash nobody hits while the embarrassing homepage typo sits there for a week. You need both.

A simple scale you can adopt today

You don't need an elaborate system. A four-level scale for each axis is plenty for most teams:

Severity: Critical (data loss, crash, security hole) · Major (a feature is broken, no workaround) · Minor (broken but there's a workaround) · Trivial (cosmetic).

Priority: Urgent (fix now) · High (this sprint) · Medium (soon) · Low (someday / won't fix).

The reporter (often the tester) proposes the severity, because they saw exactly what broke. Someone with the wider view — usually a product owner or lead — sets the priority, because that's a call about the whole product and everything else in flight. Keeping those two responsibilities separate prevents a lot of friction: the tester isn't deciding the roadmap, and the product owner isn't second-guessing how broken something is.

Triage: where the decisions actually get made

Triage is the recurring meeting (or async review) where the team looks at new bugs and assigns each one a severity, a priority, and an outcome: fix now, fix later, need more info, or "won't fix." The word is borrowed from emergency rooms, and the idea is the same — sort by what matters most so you treat the heart attack before the sprained ankle.

A healthy triage habit is what keeps a bug backlog from becoming a junk drawer. Without it, bugs get fixed based on who complained loudest or what was filed most recently — which is how the genuinely important stuff gets buried. Even a 20-minute weekly triage keeps the list honest.

And "won't fix" is a legitimate, healthy outcome. Some bugs are real but so trivial and so rarely hit that fixing them costs more than they're worth. Deciding not to fix something, on purpose and on the record, is a sign of a mature team — not a lazy one.

The takeaway

A bug is software not doing what it's supposed to. Preferences and new ideas are requests, not bugs — handle them separately.
Severity is how bad it is (technical). Priority is how soon to fix it (business). They're independent — track both.
Triage is where you assign both and decide what happens, regularly, so the team works on what matters.

Get these straight and two of the most repetitive arguments in software get a lot quieter — which frees everyone up to actually fix things.

Where to go next

Knowing how to classify a bug is most useful once you can also report one clearly, so it gets acted on. From here, the natural step is the wider picture of how quality work fits together.

Starting from scratch? The Start Here path connects these pieces into a path you can follow start to finish.

ShiftQuality