Misunderstanding of priority and severity fields has been going on for decades and suggests that they're not really useful terms.
Priority in particular is quite subjective and also changes depending on what else is going on (other tickets perhaps?)
Having said that, the bug tracker we use provides the fields by default and we try to use them intuitively. We also try to discourage the "everything is P0" behaviour that happens when people use an arbitrary numerical scale. (What even is P0? I see it pop up when people discover that all their current tickets are P1.
Anyway, here's ours. They're kind of ordered but mostly try to be descriptive and sympathetic to the idea that the judgement is subjective:
Priorities
* "If time permits"
* "Next"
* "Do not defer"
* "Blocks dependants"
* "Release blocker"
* "Don't go home"
The default is "If time permits".
Note how all of them are pretty "important" sounding except the "lowest" which instead admits that sometimes things just can't be done because of other factors rather than because they're not important.
"Next" means "do this next" or "in the next phase of work / sprint / release" and things can climb up to this priority as we take decisions.
"Do not defer" means that it must be done in the milestone it's allocated to. It can't be deferred to another milestone. i.e. we've made decisions that mean it can't be deferred to the next phase. This is for things that we'll need for the next phase or will become blockers but aren't yet. It's not for things where we have generally decided that Now Is The Time. There must be a specific reason it can't be deferred. We use the milestone features to actually decide what's in or out of a scope of work.
"Blocks dependants" is pretty high up and as such needs to be explicit about what it's used for. If your bug blocks something else or has something that depends on a fix then the schedule is going to get messy if it's not done. It's hard for someone with authority to wedge something in here because they feel like it.
"Release blocker" is also pretty high up. This is where people get to jump up and down and explain why they think their bug is so important (and why it's doesn't fit into "do not defer"). This is for stuff that means we can't actually ship the release rather than things we'd just like to be in it. For example "we can't build the software until this is fixed". Hopefully reasonably rare stuff. You need to explain why this blocks a specific release rather than the release otherwise being enough better than the previous one to deliver value to users.
"Don't go home". Sometimes things really are that bad and need to be fixed. At least the person assigning this knows what they're asking, what the implications are and how bad it looks if everything always ends up in this bucket.
Severity works a bit differently. These things are hints from the reporter about the impact of this bug. They really are very subjective.
* Don't care
* Embarrassing
* Minor peril
* Major shitstorm
* QA blockers
* Showstopper
"Don't care" is the default. We want to capture everything we know about our software and encourage people to not feel too "whiny" about filing the notes. This is often for things that end up as "enhancements" or "tasks" rather than "defects".
"Embarrassing". This is something that a user would notice and be left with an impression that we have less attention to detail than the best in the industry.
"Minor peril". This is a bug that's going to cause friction or trouble and give the user an uneasy sense or stop them from building confidence in the software.
"Major shitstorm". I'm never profane in my software but someone suggested this and lots of people liked it and had a good idea of how it should be used. This is for stuff that causes problems when the feature is used. Stuff that leaves a persistent mess that needs to be cleaned up by hand or corrupts some state or something.
"QA blockers". Without fixing these bugs then we're unable to test our software properly. This means we might attract regressions and we probably shouldn't be releasing stuff to users. For example, if you can't save a record that contains the new features then you can't test the corresponding load functionality.
"Showstoppers". These are bugs that cause the whole software to break. Crash bugs, things that destroy user data, etc.
Most of our open bugs mostly sit at "don't care", "embarrassing", "if time permits", "next" and occasionally "do not defer". If stuff starts creeping up the ladder then we know we have a problem coming. If stuff starts to appear straight at the top of the ladder then we get those things fixed ASAPs: they don't hang around as "open" for very long!
A lot of the "higher" values are things that help us deal with interactions. Problems on their own are often tractable. When things start affecting other things and causing knock-on effects then trouble occurs. We try to head that off by knowing about it when it comes in and fixing those things quickly.
Priority in particular is quite subjective and also changes depending on what else is going on (other tickets perhaps?)
Having said that, the bug tracker we use provides the fields by default and we try to use them intuitively. We also try to discourage the "everything is P0" behaviour that happens when people use an arbitrary numerical scale. (What even is P0? I see it pop up when people discover that all their current tickets are P1.
Anyway, here's ours. They're kind of ordered but mostly try to be descriptive and sympathetic to the idea that the judgement is subjective:
Priorities
* "If time permits"
* "Next"
* "Do not defer"
* "Blocks dependants"
* "Release blocker"
* "Don't go home"
The default is "If time permits".
Note how all of them are pretty "important" sounding except the "lowest" which instead admits that sometimes things just can't be done because of other factors rather than because they're not important.
"Next" means "do this next" or "in the next phase of work / sprint / release" and things can climb up to this priority as we take decisions.
"Do not defer" means that it must be done in the milestone it's allocated to. It can't be deferred to another milestone. i.e. we've made decisions that mean it can't be deferred to the next phase. This is for things that we'll need for the next phase or will become blockers but aren't yet. It's not for things where we have generally decided that Now Is The Time. There must be a specific reason it can't be deferred. We use the milestone features to actually decide what's in or out of a scope of work.
"Blocks dependants" is pretty high up and as such needs to be explicit about what it's used for. If your bug blocks something else or has something that depends on a fix then the schedule is going to get messy if it's not done. It's hard for someone with authority to wedge something in here because they feel like it.
"Release blocker" is also pretty high up. This is where people get to jump up and down and explain why they think their bug is so important (and why it's doesn't fit into "do not defer"). This is for stuff that means we can't actually ship the release rather than things we'd just like to be in it. For example "we can't build the software until this is fixed". Hopefully reasonably rare stuff. You need to explain why this blocks a specific release rather than the release otherwise being enough better than the previous one to deliver value to users.
"Don't go home". Sometimes things really are that bad and need to be fixed. At least the person assigning this knows what they're asking, what the implications are and how bad it looks if everything always ends up in this bucket.
Severity works a bit differently. These things are hints from the reporter about the impact of this bug. They really are very subjective.
* Don't care
* Embarrassing
* Minor peril
* Major shitstorm
* QA blockers
* Showstopper
"Don't care" is the default. We want to capture everything we know about our software and encourage people to not feel too "whiny" about filing the notes. This is often for things that end up as "enhancements" or "tasks" rather than "defects".
"Embarrassing". This is something that a user would notice and be left with an impression that we have less attention to detail than the best in the industry.
"Minor peril". This is a bug that's going to cause friction or trouble and give the user an uneasy sense or stop them from building confidence in the software.
"Major shitstorm". I'm never profane in my software but someone suggested this and lots of people liked it and had a good idea of how it should be used. This is for stuff that causes problems when the feature is used. Stuff that leaves a persistent mess that needs to be cleaned up by hand or corrupts some state or something.
"QA blockers". Without fixing these bugs then we're unable to test our software properly. This means we might attract regressions and we probably shouldn't be releasing stuff to users. For example, if you can't save a record that contains the new features then you can't test the corresponding load functionality.
"Showstoppers". These are bugs that cause the whole software to break. Crash bugs, things that destroy user data, etc.
Most of our open bugs mostly sit at "don't care", "embarrassing", "if time permits", "next" and occasionally "do not defer". If stuff starts creeping up the ladder then we know we have a problem coming. If stuff starts to appear straight at the top of the ladder then we get those things fixed ASAPs: they don't hang around as "open" for very long!
A lot of the "higher" values are things that help us deal with interactions. Problems on their own are often tractable. When things start affecting other things and causing knock-on effects then trouble occurs. We try to head that off by knowing about it when it comes in and fixing those things quickly.