A quick note to bjf, I also recently bought a Nikon FM3A and I love it. I chose it because of it's classic design and reliability, and I'm glad to see not everything is going digital.
The next pattern in Defect Tracking Patterns is the one that has generated the most commentary so far, often because of confusion over the terms.
Differentiate Priority and Severity
The effect of a bug on the software does not automatically correlate with the priority for fixing it. A severe bug that crashes the software only once in a blue moon for 1% of the users is lower priority than a mishandled error condition resulting in the need to re-enter a portion of the input for every user every time.
Define a range for Severity as "how bad does it hurt?" according to project requirements. One example of a range in use is
- Enhancement: New features
- Low: Improvement to existing code, e.g. performance enhancement, or problems with an easy workaround
- Normal: Broken or missing functionality
- High: Problems causing crashes, loss of data, severe performance problems or excessive resource use.
- Blocker: Problems that prevent testing or development work
Define Priority according to business value and project timelines. High priority bugs should be first to be fixed.
Importance and Destructiveness are alternate words which may be clearer to some.
An example of the difference and interaction is in bugs that are purely cosmetic problems, misspellings in dialogs, redraw issues, etc. These can be priority 1 fairly often, because they are frequently very annoying to users, and fixing them is generally easy and doesn't destabilize things.
Track priority and severity separately, then triage appropriately. It helps to have input from others on the team on priority. The importance of a bug is a project decision, different from the bug's perception by the Customer. In some cases it makes sense to track Urgency, the customer's point of view, separately.
The Developer, when determining what to work on next, would pick the bugs with the highest priority, regardless of severity. The Dispatcher is responsible for setting these appropriately, especially in the case where the Customer marks everything Very Severe and Highest Priority.
Extreme Programmers may see a resemblance to Story Cards and the Planning Game.