There are several topics that can trigger near religious fervor in software developers--languages, indentation, and comments come immediately to mind. One of Peter Clark's personal favorites is the relationship of issue priority to issue severity in defect tracking systems. Just what the heck do all those levels mean, anyway? In this week's column, Peter describes a solution that his company devised to clearly define the characteristics of severity and priority and help them better understand how the two work together.
Not all requirements are created equal. Some requirements are more central to the purpose of an application than others. For example, our company produces airport baggage handling systems. While it is important that the reports show the right numbers, it is absolutely central to the system that bags are delivered to the correct flight. An issue that prevents that, or that causes a potential safety hazard will be assigned the highest severity level.
Issue severity has to do with the impact of the defect in question to system end-users. Software is developed to achieve a purpose; issues get in the way of achieving that intention. Just how much the issue obstructs achieving the goal determines the severity of the issue.
Our company uses five levels of severity:
- Showstopper--either a safety issue or an issue that affects a central requirement for which there is no workaround. It prevents either use or testing of the system.
- High--an issue that affects a central requirement for which there is a workaround. Use or testing of the system can proceed in a degraded mode.
- Medium--an issue that affects a non-central requirement for which there is no workaround. The feature cannot be used.
- Low--an issue that affects a non-central requirement for which there is a workaround.
- Cosmetic--information is correctly shown but the appearance is wrong, such as misspelled words, wrong font, wrong indentation, etc.
Issue priority is the order in which issues are addressed by developers. In our company, issues are triaged by supervisory personnel, who may adjust the severity level and who will then assign the issue a priority and dispatch it to a developer for remediation.
Our company uses four levels of priority: urgent (drop whatever else you are working on and fix this now), high, medium, and low. Developers are expected to remediate issues in priority order: first urgent; then high; then medium; and finally low.
We don't always fix issues in order of severity. I may assign less-experienced developers a medium or low issue, even though outstanding showstopper issues still remain. I may do this because they have no experience with the sub-system where the showstopper resides, and there is no one available to mentor them as they fix it. Or I may have a low severity issue that is on a customer punchlist and must be cleared before we can get paid, so I give it a high priority.
The notion of issue triage requires an adjustment by developers. Often, they will want to work on their own pet issues first, rather than working on issues that I assign to them in the order that I want them addressed. They will attempt to get around these restrictions by inflating the severity of an issue when they log the issue into the tracking system. This is why supervisory personnel adjust the issue severity prior to assigning it. It is expected that supervisors will be more dispassionate than the developers, and that they have sufficient domain experience to correctly assess an issue's impact.
There is little point in having a separate issue prioritization scheme if you do not have a single point of issue triage. If developers are selecting their own issues from the issue tracking system, it is usually sufficient to have them address issues in order of decreasing severity.
Our issue tracking system has the concept of deferred issues. A deferred issue is one that we are not going to address at this time. A feature may not be needed in a particular release of software, or it may occur so infrequently that we deem it unnecessary to ever fix it. Yet we don't close out the issue, so it will keep some level of visibility in our system. Deferred issues may be addressed under a product development project, or if I need to find work for personnel during a slow period.
Issue severity gives management a good impression of the current state of the software being developed. It also serves as a foundation for establishing issue priority. Issue prioritization gives developers a clear understanding of the order in which they should work on their defects.
Despite the risk of "technical radicalism," when issue severity and priority travel hand in hand, managing developers can make informed decisions on work order and can support their choices with documented information.
