Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
If this question can be reworded to fit the rules in the help center, please edit the question.

10

Why do you have impossible-to-understand names like "low", "medium" and "high"? Why don't use just use real words like "crash", "corruption", "known workaround", and "annoyance"?
–
S.LottMar 11 '11 at 14:50

Because I have nothing to do with the naming of the priority levels. I just get to use what is given to me. I do like your names for them though.
–
ErinMar 11 '11 at 14:52

1

We have a 4th level, "Critical". It's the worse of the one's you'd classify as "high" (eg. sudden production server failure).
–
FrustratedWithFormsDesignerMar 11 '11 at 14:55

1

I find Low is never used... everyone says its Medium, High, or Urgent
–
RachelMar 11 '11 at 15:18

1

@Thorbjørn When an error takes more time to put under tracking than to just fix right there when I noticed it, I tend to just fix it. (Mind you, we don't have a formal QA process, so no one else's job is to put bugs in the tracker. It's more of a "to do later" list for us than a work queue from someone else.)
–
CodexArcanumMar 11 '11 at 15:43

11 Answers
11

We classify our bugs and defects according to both their priority and severity.

The priority level is an indication as to how urgent it is to fix/correct the problem (urgent, high, medium, low, none).

The severity level, helps us identify how much or what kind of damage can be caused by the defect (dangerous/destructive, degraded and no workaround, affected but workaround exists, nuisance/cosmetic, no impact).

Typically, the more dangerous and destructive the bug is, the higher the priority. However, it is not guaranteed. Consequently we can wind up with the occasional bug listed as dangerous and destructive, but due to the rarity of the situation, or the amount of change that may be required to fix it, its priority can in theory become quite low.

Medium -- Functionality that would improve the ease of use for customers/field technicians. Stuff that saves people time.

Low -- cosmetic things

I imagine the levels of severity/priority will be drastically different if you're making a web app and you have a completely different buisiness model/customer base. Its ultimately about what your customers expect and how angry they get about the issue :)

For the moment, we're using the default bug classifications that ship with JIRA: blocker, critical, major, minor, trivial (described in more detail here).

I really like the "user pain" scheme of classifying bug severity described in "Improving Bug Triage with User Pain": rate bugs on three simple scales (type, likelihood, and priority), then multiply those values together to prioritize bugs. However, I haven't implemented it myself.

I've come across all sorts of schemes because they all depend on the company and industry. When I've worked in the auto industry, we usually use a (company specific) name to match the severity numbers from a FMEA. Generally the lowest levels would be called "cosmetic" while the top 2 levels would be "injures lots or kills one person" and "kills lots of people" respectively.

To your list of "low, medium and high" one could also add "critical" and "catastrophic." Depending on your industry, "critical" might involve loss of money and customers, while "catastrophic" involves breaking regulations and laws that can get you shut down.

When you are not allowed to work on some thing unless it is in your list of approved work orders that doesn't work.
–
ErinMar 11 '11 at 16:08

@Erin - right. This only works in a Lean environment. But even with a list (to which you are referring, I think) this will work as long as the list is limited to only a few (e.g. 2 or 3) items, known as Kanban: en.wikipedia.org/wiki/Kanban.
–
WikisMar 11 '11 at 16:17

Wouldn't that mean you disrupt working on something else? I can't imagine something like that working with any kind of complex task.
–
IncaMar 11 '11 at 18:44

@Inca - it depends. You may split your team into two groups - those who work on structural important requirements for the next release, and those (a small group, typcially) who work on lower priority issues and who can indeed drop everything to fix an important defect.
–
WikisMar 11 '11 at 19:50

@Wikis, but isn't that exactly what prioritizing does? Deciding which things can be dropped, and which need immediate attention? Ok, in that scenario you do not classify bugs, but you classify the work someone does, but issues are still classified.
–
IncaMar 11 '11 at 19:55

Those you must fix.
Those you would like to fix.
Those that have nothing to do with functionality and only get fixed if you somehow magically finish every other task and are sitting around and have tired of playing XBox.

Your classification system needs to take into account several factors.

Detection:

Does the bug show up obviously? Does the software report an error to the user or administrator when it happens? Do the logs show clearly what's going on? Even if the bug is an unexpected corner case, if you show an error to the user "dividing by zero isn't allowed" then you have averted the error cascading into future problems and creating a snowball of damage.

On the other hand, the bug may not trigger any error reports, not leav an obvious trace in the logs, not be detected until long after it does the damage. You could ship a thousand units to the wrong address and not know it until weeks later when your customers call you up complaining about where's their stuff.

Show Stopper:

In the theatre "the show must go on". Unless the stage is on fire, in which case you have to evacuate the theatre and give the audience their money back. Hence the term. You have to shut down the system because it won't work until you fix it.

Data corruption, damage, injury, death

Most bugs cause something to not happen. Some bugs cause bad things to happen. Maybe it overwrites records in your database, causing data loss, forcing you to go to backups.

Maybe it causes damage to some kind of physical system. If it's a system with a physical output it could cause actual physical damage to people, kill someone, drive a train off the tracks, etc.

Systemic

Some bugs are not the problem, but a symptom of deeply flawed code. The developers are not competent enough and have created a fragile brittle system that can't be added to any more without collapsing. Push down a bubble in one place and it pops up in another.

In this case it's more about firing the programmers and doing a major rewrite.

Other:

Aside from those, it's basically an inconvenience. Prioritize based on soft things like how many people are complaining, what management wants, your own personal feelings, throwing darts at the wall, etc.

Something that wasn't said in the current answers: there must be 4 levels. Not 3, not 5, but 4. It's an important number, because then you can't have a "middle". You have to choose if it's less than or more than average.

Something else that wasn't said but has a word:

In project management, there is an often used tool: a risk matrix. It defines risks according to 2 criterion: severity and the probability. This should remind you of other answers in this thread.