In bug tracking tools (and probably other similar applications), tickets are prioritized based on discrete categories rather than on continuous values.

This can produce strange and counter-intuitive situations. For example, if the same developer has twenty tickets assigned to him, and three of them have immediate priority, what does it mean? Which one, among three, is more immediate than others? Which most be solved first, taken that all require lots of work? Or must the developer be a three-headed dragon to solve those three tickets in parallel?

Instead, continuous priority indicates that the third ticket must be solved before the fourth one but after the second one which is itself less urgent than the first one. Everything becomes easy: you start from the top, and you go down until you solve the last ticket, those tickets being ordered through a drag-drop by the project manager.

So is there a reason explaining why bug tracking tools use discrete categories, or is it just because it was "always done like this, forever"?


Couple of reasons.

Firstly, as @Chase noted, discrete values make more sense because it's relatively easy to determine the importance of the bug, but it's often meaningless to prioritize it over other bugs of the same importance. It will require the QA guys to dedicate a lot of time to thinking over the priority of each bug, comparing it to other bugs and possibly consulting with team members. The decision, as far as they're concerned, is actually arbitrary, and when you force them into making such decisions, it requires a lot of effort. It's just a lot of wasted time. On the other hand, it may not be arbitrary for the developer, who can see that a specific bug from the same group should be dealt with first, and that might take care of other bugs. So this method lets the right party exercise their judgment, and relieves the "wrong" party from struggling over pointless decisions.

The second thing is that in most cases there are many people submitting bugs. How would they prioritize over other people's bugs, that they aren't familiar with? And you can't just let each person prioritize his own bugs and then merge them into a big prioritized list, because someone needs to make those decisions.

  • 1
    +1 Priority is used to coarsely define the severity of a bug, not its urgency, which is another (and not the only other) factor in deciding which bugs gets solved first. In fact, a low priority bug with a high urgency often gets attention before a high priority low urgency one. – Marjan Venema Aug 6 '11 at 9:35
  • I don't think people submitting the bug should be the ones deciding on a bugs priority at all. At least not in a ideal situation. – Lode Aug 7 '11 at 13:33
  • @Lode in an ideal situation there won't be any bugs to begin with ;) – Vitaly Mijiritsky Aug 7 '11 at 13:39

Speaking as a potential user of a bug tracking system, having discrete values makes more sense to me. Some bugs are high priority, some are low, etc. Who is to say whether one high bug is more critical than another? Besides, bugs typically take just a few minutes to fix, so you will likely be closing a bunch at once, or at least all in the same version/deploy.

If a bug is REALLY critical, you can bet someone important will come over and demand that you stop everything else and fix it. In that case, a bug tracking system isn't really necessary.

On the other hand, continuous values make more sense to me for NEW work, such as tracking new feature stories. For Agile in particular, it's critical to be able to pick the "next" X units of work from the larger space of all work that could be done. Having more than X units of work all in the same "high priority" bucket doesn't get you where you need to be.

  • "Bugs typically take just a few minutes to fix" What do you work on? Some bugs take only a few minutes to fix, most bugs in code development are a bit harder. A bugreport like: "It doesn't work", doesn't tell you much when what they mean is "In situation A, provided B and C, X and Y are happening when it should be Z." Then you gotta be able to reproduce it, which in itself can be a challenge. Only then can you track down what's causing it, fix it, prove it and prove the fix hasn't broken anything else. All in all, depending on the complexity of the application, minutes aren't gonna cover it... – Marjan Venema Aug 6 '11 at 9:33
  • Maybe I was overstating it, but I maintain that the median time to close a bug is in minutes. Think of all the display issue bugs and bugs you close while the feature is still in active development. – Chase Seibert Aug 6 '11 at 14:05
  • Well I guess our mileage varies and/or you just haven't worked on the kind of systems I do: heavily multi-threaded back end servers and supporting tools. In a set of appr. 50 executables, only 2 have a GUI. As such the GUI's are an important but relatively small part of the software suite I work on. And so the bugs reported to us have very rarely to do with display issues. Even when the are reported against/through the GUI (coz that's what users face), the bug usually isn't anywhere in the GUI, as that, well, just displays our stuff. All logic is elsewhere... – Marjan Venema Aug 6 '11 at 19:09

A developer would prefer to have 3 'immediate' priority bugs and retain the flexibility to choose which one he/she wants to fix first I think.

Only the guy coding would know which bug is easier to fix than the other and tackle it first, 'Shortest Job First'. If everything seems the same or cannot be resonalbly estimated then just nail the oldest one first.

I agree with Chase Seibert, if it's a show-stopper then someone will likely tell you that.


I am using both FogBugz and Pivotal Tracker. FogBugz is based on categories and Pivotal is based on a continuous scale.

Agile development / Pivotal advocates that the product owner or the scrum master should decide on the priority. And then, to my experience, the priority is not that strictly tied to one bug anymore. The priority becomes a mix of the effects of fixed the bug and the direction the business is heading to at the moment. This will change constantly, and often should not be set by the submitter of the bug, or at creation of the bug either.

This is really the way that Pivotal Tracker works. On submitting a bug lands in a general pool of bugs. And only when you get it out of there you give it a priority, which is generally done by the product owner or at team meetings.

As notes by others as well, people have trouble with - and misuse - the difference between priority and severity. The severity of a bug is something that can be estimated by the submitter, and probably be confirmed or changed by the programmer or the product owner. The priority should be in the hands of the people making the decisions, not the people who find or fix bugs.

But it might be that you don't have an organization in which a product owner gives priority and direction to the development that closely. Then it can be very handy that people who work with the individual bugs (submitter and fixer) actually set a priority based on their own experience of previous bugs.

But also in those situations I often find that submitters can't set the priority of a bug that freely. Or only to values 2 to 4 (on a scale of 1 to 5) for example. Only other people using the system - maybe the programmers or the product owners) can set the priority.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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