Igor Yussupov
Severity is how much damage a bug does. Priority is how soon the team should fix it. They are separate questions with separate owners: severity describes the problem and priority is a scheduling decision. A bug can be severe and low priority, or trivial and urgent, and a team that treats the two as one scale ends up arguing about every ticket. Below are the definitions, a matrix with an example in each box, and a way to stop the arguments.
The definitions
| Severity | Priority | |
|---|---|---|
| Question it answers | How bad is the effect of the bug? | How soon should we fix it? |
| Based on | Impact on the system and its users, regardless of timing | Business needs: deadlines, customers, risk, effort |
| Usually set by | QA or the person who triages | Product owner or project manager |
| Changes over time? | Rarely. The bug does the same damage until it is fixed. | Often. A launch date or a customer complaint can move it. |
A useful shortcut: severity is a fact about the bug, and priority is a decision about the team's time.
The four-box matrix
Put the two scales against each other and each combination has a recognisable kind of bug.
| Low priority | High priority | |
|---|---|---|
| High severity | Serious but not urgent. The invoice export crashes, but only for one legacy report that nobody has run in a year, and there is a workaround. Fix it when the area is next touched. | Fix now. Customers cannot complete checkout. Data is lost. A payment is taken twice. Everything else waits. |
| Low severity | Fix if there is time. An icon sits two pixels out of line on a settings page. A rare tooltip is cut off on a small screen. | Cosmetic but urgent. The company name is misspelled on the homepage the day before launch. The client's name is misspelled in the header of the demo you are showing them tomorrow. |
The two off-diagonal boxes are the reason both fields exist. If you only track one, you either bury the typo on the homepage or you drop everything for a crash that affects nobody.
Example scales
Pick scales your team will actually use. Four levels each is enough; more than that produces debates about the difference between level 3 and level 4.
Severity
| Level | Meaning | Example |
|---|---|---|
| Critical | The system is unusable, data is lost or security is compromised. No workaround. | Login fails for every user. |
| Major | A main function is broken, or the workaround is painful. | Filters on the orders list return the wrong rows. |
| Minor | A function misbehaves, but there is an easy workaround. | Sorting resets after saving. |
| Trivial | Cosmetic or wording, no effect on the task. | A button label is mis-capitalised. |
Priority
| Level | Meaning |
|---|---|
| Urgent | Fix before anything else, including today if needed. |
| High | Fix in the current sprint or before the next release. |
| Normal | Schedule in the normal flow of work. |
| Low | Backlog. Review it from time to time. |
These are examples, not a standard. What matters is that every level has a one-line definition and a real example from your own product, written down where testers can see it. The examples in the bug report templates post include a short severity table you can adapt.
Who decides which
- The reporter describes the problem. They say what happened and what they expected. They may suggest a severity, but a suggestion is all it is, because reporters judge from their own corner of the product.
- QA or the triage owner sets severity. They know how the system behaves and can check whether a workaround exists.
- The product owner or PM sets priority. They know the deadlines, the customers waiting and the cost of delay.
- Developers advise on effort. A cheap fix to a low-severity bug may jump the queue; an expensive one may not. That is a priority input, not a severity change.
SnagRelay does not rate either one for you. The reporter sends what they found, with the evidence, and your triage owner rates it in the tracker the way you already do.
Stopping the arguments
- Write the scales down with an example per level. Most arguments are about unspoken definitions.
- Keep the two fields separate. Do not let "Critical" quietly mean "urgent". If a typo needs fixing today, set the priority, not the severity.
- Leave severity alone once set. If priority changes, change only the priority. Otherwise reports and trends stop meaning anything.
- Review the pairs, not just the lists. In triage, read each bug as a pair. High severity with low priority needs a sentence explaining why, so it does not look forgotten.
- Do not let the loudest person decide. Priority is the product owner's call, made against a known list.
How to set up the fields
Most trackers give you a priority field out of the box, and Jira has one by default. Severity is often missing or has to be added as a custom field, so check yours before assuming it exists. Whichever tracker you use, make both fields visible in the board view, so a high-severity, low-priority bug is easy to spot. For a bug report that helps the person rating it, the information that matters is what developers need in a bug report: the steps, the error and the impact.
FAQ
Can a bug have high severity and low priority?
Yes. A crash in a feature that almost nobody uses, with a workaround, is severe in effect but can wait. Fix it when the area is next touched.
Can a bug have low severity and high priority?
Yes. A misspelled company name on a landing page is trivial in technical impact, but if the page goes live tomorrow it is worth fixing today.
Who should set bug severity?
The QA lead or whoever triages, based on impact and whether a workaround exists. Reporters can suggest a level, but they usually see only their own use of the product.
Who should set bug priority?
The product owner or project manager, because priority depends on deadlines, customers and cost, which engineers and testers do not see in full.
Do I need both fields?
If your backlog is small, one is fine. Once you have enough bugs that people ask "what do we fix first, and why", the two questions need two answers.