Bug Severity and Priority
Mark Kampe
In a large project there are likely to be many bugs ... sufficiently
many that they will not all be fixed promptly. It becomes necessary
to decide which bugs to fix sooner, and which to fix later. Long ago
battle-field doctors learned to divide caualties into three groups:
- those who would almost surely die (treatment wouldn't make a difference).
- those who would almost surely live (treatment can be delayed).
- those who could be saved if treated promptly.
Taking a few minutes to perform this sorting (called triage,
in reference to the three groups)
greatly improved the effectiveness of battle-field medicine. A similar
process is followed with bugs ... although hopefully without a class
of problems that will doom the product regardless of any action on
our part.
Bugs are, to a first approximation, dealt with on the basis of their
severity and priority. Because these two words
determine which bugs will be fixed, control over the defintion of
these terms translates into control over what work does and does
not get done. Arguments that would seem to be about the meanings
of these terms are often political arguments in disguise.
There are no universally accepted definitions for
these terms, but I will try to give you a foundation from which you can
enter into discussions on the subject.
- severity
is probably the better defined of these two terms, and is
usually taken to be a measure the consequences to the victim.
System failure and loss of important data might be consdered
to be very severe, confusing error messages might be considered
to be of relatively low severity.
There may be standards for grading severity, like:
- permanent data or service loss.
- unable to use primary functionality
- impared use of primary functionality, or
unable to use secondary functionality.
- minor inconvenience.
- suggestion.
Many organizations adopt the convention that the
severity of a bug is owned by
the submitter (the submitter gets to determine how
seriously she was impacted).
- priority is a concept with a much wider
range of meanings. The most cogent meaning I have found
is that it is a measure of the importance (to the project)
of fixing this bug. The severity is
surely one of the factors in determining this, but there
may be other equally important factors:
- how likely it is that others will encouter the problem
- the availability of a work-around
- the expectations that have been set for the product in question
In keeping with such a defininition the priority
of a bug is owned by the product owner, and a
priority scale might be:
- must fix immediately.
- must fix in next release.
- should fix in next release.
- fix when it is convenient.
- may get to it some day.