I understand what they determine but is it really useful to assign those to issues found? I mean, it is either required to fixed quickly or not.

I know how to set them, categorize them etc. I know IEEE/ISO do require to do that. I just do not see why.

  • Hmm, I think a bug that would damage data is more severe than something that is just annoying like say some functionality taking too long to load. Both should be fixed but those with higher negative impact should be fixed first. Dec 1, 2015 at 9:43
  • No, as I wrote I know what they are or how to set them. I just do not se ethe benefit.
    – Pietross
    Dec 1, 2015 at 9:56
  • 6
  • In most cases, no. But there are always edge cases where it makes sense to separate the two. Whether the separation is worth maintaining for every issue just to cater for those rare occasions is another matter.
    – biziclop
    Dec 1, 2015 at 11:49
  • 1
    You can have a UI bug that doesn't really affect he apps usability (low severity), but is a high priority because it's ugly. You can have a bug that crashes the app completely (high severity) but is a low priority because the conditions to make it happen are one in a million and in all practical terms will never actually happen (this ignores the fact that one-in-a-million chances come up nine times out of ten). Dec 3, 2015 at 20:47

7 Answers 7


It is absolutely possible to have those values differ. If you have a sale to make to an important government agency that requires high performance but won't ever use module X, then it makes a lot of business sense to fix a minor database availability error sooner than a severe error in the X module. Basically, technical reasons are not the only factor when you run a software business.

  • Exactly: Priority indicates business value and is the result of project management. Severity indicates impact and is the result of bugs. Every task can have a priority, but e.g. new features don't have a severity. Aside from security-critical high-severity bugs, it would be foolish to let severity alone dictate priorities, or people would be mis-incentivized to overstate their issue's severity.
    – amon
    Dec 1, 2015 at 13:22
  • 5
    I think the important thing is that only one measure (the priority) controls the order of development directly. How useful a team finds an additional "severity" as part of a defect description is extremely opionated: some might find it helpful, others like @arnaud think it is "bureaucracy" - both points of view might be reasonable.
    – Doc Brown
    Dec 1, 2015 at 14:51
  • 4
    High Priority, Low Severity: The landing page of your application, seen by millions of users a month, has a typo in your company name. Low Priority, High Severity: System crashes 25% of the time on startup for an application that is being retired next week. Dec 3, 2015 at 21:18
  • 2
    Severity can generally be determined by rules by automated and live testers. Priority can only be evaluated subjectively by the business. Dec 3, 2015 at 21:20

Date and time bugs

Bug: Year-end processing will totally corrupt your database. That's clearly a severe bug.

Date: December 15. The bug is very high priority.

Date: February 1. The bug is low priority.

Accidental launch of missile bug

Bug: ICBM control software pukes when going from Feb 28 to Mar 1 in years divisible by 4. The result is an uncommanded launch.

That's about as severe a bug as can exist. Priority very low, though--is there any realistic chance the software will be in use when the condition is triggered?

Inadvertent 'bad' words on screen

Bug: Messages overflowing their space on the screen result in an inadvertent profane reference to Bob appearing. (Real world: We had people working in the "Final Ass" department. "Ass" = "Assembly".)

Unfortunately, tomorrow you are making a presentation where getting the sale is make-or-break for the company. You are making the presentation to someone named "Bob". Severity: Very low. Priority: Very high.

  • Related to the 'overflow' and 'date time' bugs you mention - you may enjoy phase of the moon bug
    – user40980
    Dec 7, 2015 at 21:20

You wrote:

I mean, it is either required to fixed quickly or not.

That is correct. If you are like most companies, however, your resources are limited. Either you don't have enough people to fix all of the issues, or you don't have enough time.

Given the fact that a bug is either required to be fixed quickly or not, and you have lots of bugs that need to get fixed, "priority" answers the question "which one do I fix first"?

Severity, on the other hand, is an indicator used by the person setting the priority. From a developer's point of view the severity is a moot point. From the perspective of the one assigning work, severity is an important piece of information that helps with the decision making process.

Of course, all of this is very general information. If you are a team with an impossibly long backlog of bugs, priority and severity mean something completely different than if you are on a team that has a near-empty bug database.

If you're on a team where "high severity == high priority" none of this matters and you don't need both metrics. At the end of the day, these are just tools. Your team needs to decide how to use them. For your team it may not make sense to use both.


IMHO, putting both Priority and Severity is just bureaucracy.

In practice, you just need one measure of "importance". Often, priority is used for it, and severity is then used as technical term like "high = crashes system or makes it unusable", "medium = buggy behavior, potentially harmful", "low = nuisance, annoying but harmless"

Usually, priority goes hand in hand with severity. A few counter examples are a "nuisance where everyone always complains" or a "crash having occured once in an exotic environment".

...but, in the end, as a developer (or manager, etc) you only need to know in what order you should fix/improve things, that's all. So one measure is enough.

The need of priority is clear: it's to know in what order the bug reports should be tackled. The other one, IMHO as usual, is bureaucracy. Why do you need it? It's apparently useless for sorting because priority does that. And the consequences (severity description) is described in the bug report anyway.

I even think it is harmful because it makes it less clear what bug is more important:

  • Some may think a "critical" bug has higher priority than a "high-priority" bug.
  • Some users reporting a bug may confuse severity and priority
  • ...altogether, it rather adds confusion as to what order the bugs should be tackled
  • 1
    And are developers the only people that matter?
    – biziclop
    Dec 1, 2015 at 11:50
  • 2
    @biziclop Nope, you are right, it was a poor formulation of mine. It holds for everyone: what matters, for managers, etc, too, is what should be fixed first, and what is less important. For that, one measure is enough.
    – dagnelies
    Dec 1, 2015 at 12:10
  • 1
    Well, it is wrong from risk management perspective - priority=severity*rate of occurrence. Is a typo on the frontp age lower priority than a fatal server crash that happens if user last name exceeds 46 characters?
    – Pietross
    Dec 1, 2015 at 12:58
  • 1
    @Pietross: well, you pinned it down: which one should be tackled first? The low priority sever crash or the high priority nuisance? How do you prioritize? Who makes that judgement call? Everyone looking at the list? When using only one priority measure, it prioritized once, then it's done. The impact and severity is described in the bug report anyway.
    – dagnelies
    Dec 1, 2015 at 14:04
  • The thing about "severity" is you can pretty easily say "crash = high, typo = low". It takes thought to realize that a typo that leaves 'o' out of the word 'count' on the homepage is higher priority to fix than the page refusing to load at all. Dec 4, 2015 at 1:24

In addition to other answers, consider this scenario: bug A will take 30min to fix and has 'low' severity; bug B may take 2+ weeks to fix and have 'high' severity. In addition, bug B may take a lot of discussion and coordination in dev team and perhaps outside of team; bug A may be fixed by single dev immediately. It's perfectly fine to set higher priority on bug A.

Of course 'severity' and 'priority' may be interpreted in different ways.

In a small bug tracker I made for my own use I instead preferred 'difficulty' and 'priority' where high severity issues would always have highest priority, and I might decide to delay working on them based on difficulty.

One thing I don't like about 'severity' is that it only applies to bugs and not features. It may be better to have a single list of all issues ordered by priority and difficulty as it's more directly helpful to decide 'what do I work on next?'.


I have designed and implemented processes in a software company that were certified ISO9001:2007. There have been updates to the standard since 2007 so there may be additional requirements that I am not aware of... however:

The ISO9001 standard is about ensuring that your company designs and implements processes that have feedback loops for improving the process when product and process defects are identified.

During the design phase the requirements focus on whether the proposed solution if implemented correctly would actually solve the design brief (validation) and checking whether the implementation actually has been implemented without defect (verification)

On the feedback loop, when defects are identified, it’s not enough that they are recorded. A defect also needs to be assessed for severity, and the rework prioritised.

The key part, is that how your particular company decides to assess its severity, and make decisions about priority is not defined by the ISO standard. It’s a commercial and governance issue for the company to decide and document.

As it is written into the standard as a requirement, any certified company will have a process around assessing the severity of a defect and a process in determining the priority of the work to fix the bug. They are definitely two seperate decisions that need to be made.

Severity of the bug is only one data point. Customer impact Is another data point. There’s also effort to fix, defect age, commercial life remaining in the product, and any other factor that the company decides to include in its decision making. The one thing it should not be written as “present defect to product manager to decide priority” as that only defines the authority to make the decision and does not define the process they they follow to make the decision.

I have a preference for prioritisation that is biased towards delivering a high rate of small and important changes, as this seems to provide the best boost to overall product reliability. This means that a severe bug that will take a lot of work to fix would need its work breaking down into smaller chunks to get sufficient priority to get scheduled.


For reason to strongly differ priority and severity:

A simple example. Imagine the case you have a narrow place that prevents scaling of your system - some algorithm has complexity O(N^3), where N is count of client's stores. The client says it will open 200 new stores the next year, and the needed calculations (goods distribution, transportation planning, etc.) won't be finished in time. But, currently this client has only 30 stores, and resources are enough. The task to optimize this algorithm (to O(N^2) or better) is definitely important (you'll lose the client if not implemented), but likely not urgent: you have a few months to implement the new algorithm.

Example 2: an application crashes systematically, but this version gets out of usage in a few days due to upgrade or migration. Fixing is urgent because crashes really affect user experience, but is of low importance.

Of course, both parameters are unified using some metric (either formal or informal) to produce a short-term work plan, because the latter is single-dimensional (sequence of tasks). But in long term view they shall not be unified.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.