I've never really liked the priority or severity fields on bugs.
"Priority" feels to me like a band-aid on a UI deficiency in many electronic issue tracking systems: No way to manually sort the bug queue. If I can manually sort, it's easy for me to quickly find a spot where it's directly between something I'd rather have fixed sooner, and something I'd rather have fixed later. Which is ultimately what prioritizing really is - anything else is just beating around the bush.
And I don't believe that "severity", conceptualized as a linear scale, is meaningful. Whenever I see "severity X", my very next question is "why?" The severity score itself is, at best, not particularly actionable, and, at worst, something other stakeholders will learn to use as a vehicle for squeaky wheel prioritization. Or an agent for semantic rot, as someone decides to try and make the severity scale meaningful by imposing a strict hierarchy on all the possible kinds of things that might go wrong. (Or, rather, all the ones they thought of at the time.) I'd rather see tags like "data loss" or "known workaround exists". They paint a clearer picture, and they're harder to game.
- Risk of too much discussion on exact ordering. I think to my uses of graphical programming languages vs text and having infinite places to put wires made me waste more time on perfecting it than the coarseness of text.
- Sometimes there is not clear priority between multiple tasks
- Sometimes you want to think locally. I might be looking at a ticket and I'd like to know the general bucket it is in without having to look at it in context of the entire table. I might also want to triage it and put it in a bucket without trying worrying about the exact order.
I think a potential is to combine the two. You define discrete priorities and have dividing lines in the UX. The UX can let you drag between buckets or even order within a bucket.
This is one of those spots where I think that Scrum gets things right. Having the ticket priority ultimately belong to a single person (the product owner) sets up a pretty decent incentive structure. It makes it easy for that person to figure out on their own exactly how precise they need to be, and where the precision is needed, in order to get their job done.
When I see over-polishing happening in the wild, it tends to be in response to "too many cooks in the kitchen" type situations. Well, that or procrastination.
I've considered whether a hot or not type system could be used to rate the priority of bugs / tickets. It would present a summary of two tickets and make implications based on which one the user said was more important to order the whole backlog. I'm sure there is a fundamental flaw somewhere but I like the concept.
My main issue with allowing people to define the ordering is that, in my experience, enevitably you have some stuff at the top, some stuff in the middle and a big mostly unordered heap in the middle.
For the record, Microsoft's TFS/VSTS/AzureDevOps/whatevername has manual sorting of the bug queue. So we can drag-and-drop prioritize our work queue. However, the feature is supported very inconsisently, at least on the version we're using on our system. Many important searches and views don't sort by priority.
Yeah, all issues in the backlog should be sorted by priority. But a separate priority flag is still useful to indicate critical bugs. A high priority issue means you should drop everything and deploy a hotfix ASAP. This is not communicated by just moving the issue to the top of the backlog. But no need for multiple levels.
"Priority" feels to me like a band-aid on a UI deficiency in many electronic issue tracking systems: No way to manually sort the bug queue. If I can manually sort, it's easy for me to quickly find a spot where it's directly between something I'd rather have fixed sooner, and something I'd rather have fixed later. Which is ultimately what prioritizing really is - anything else is just beating around the bush.
And I don't believe that "severity", conceptualized as a linear scale, is meaningful. Whenever I see "severity X", my very next question is "why?" The severity score itself is, at best, not particularly actionable, and, at worst, something other stakeholders will learn to use as a vehicle for squeaky wheel prioritization. Or an agent for semantic rot, as someone decides to try and make the severity scale meaningful by imposing a strict hierarchy on all the possible kinds of things that might go wrong. (Or, rather, all the ones they thought of at the time.) I'd rather see tags like "data loss" or "known workaround exists". They paint a clearer picture, and they're harder to game.