Discrete priority values instead of continuous ones in bug tracking tools

Question

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"?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.