Bugs are the inevitable bane of every software developer’s existence (of course.) Just as inevitable is the question of when to fix them.
“When should we fix this bug?” is usually addressed through some sort of prioritization scheme, and at many companies that’s driven by severity. A bug’s severity is usually determined by the impact the bug has on clients, the effort involved in the fix, etc. Here are just a few considerations that may come into play:
- How many clients are affected? (Usually one, some, or all)
- Are the clients able to use the software at all? If so, how severe is the loss of functionality?
- Is there a workaround for the problem until the bug is fixed?
- Does the company have an SLA with the affected clients?
- How hard is it to fix the bug?
- How risky will it be to deploy the fix?
This typically results in a bug prioritization scheme that has four (or more) levels. Unfortunately, having four or five (or more) prioritization levels creates more problems than it solves:
- Prioritization levels tend to work their way into the language of SLAs and reports to management, which makes them hard to change.
- As the number of levels goes up, the distinction between them tends to get fuzzier, and the challenge of categorizing bugs gets harder.
- Even with relatively few levels, it’s hard to distinguish between those at the bottom of the scale.
- The bottom-most priority level bugs never get attention. Ever. They might as well not be there.
In other words, too many bug priority levels produces too much confusion and delay.
Bug Prioritization for Iterative Development
Many Agile shops follow development process frameworks like Scrum that operate in iterations called sprints. A sprint is simply a period of time in which software development work is planned, conducted, and delivered; this cycle is then repeated, iteratively. It’s a bit like doing laundry: 1) sort out the clothes to be cleaned; 2) wash, dry, and fold them; 3) put them away in the dresser. Repeat from step one.
The industry standard for the length of a sprint is two weeks, but it varies from shop to shop. Regardless of how long the sprints are, there are only three priority levels needed to classify bugs for an iterative system:
Fix It Now
Our product is really broken. Many or most of our clients can’t get their work done, period. It’s worth sacrificing some or all of the current sprint’s planned work that’s not yet done to get the problem solved as quickly as possible.
Fix It Next Sprint
Our product is broken, but there are workarounds or sacrifices our clients can live with until we finish off the work we’d planned this sprint. We’ll put the bug at the top of the priority backlog for fixing in the next sprint.
Fix It Later
There’s some sort of noticeable defect in our product, but it’s not slowing our clients down significantly, nor is it preventing them from getting stuff done. It can wait indefinitely.
Bug Prioritization for Continuous Development
Some Agile shops operate in a framework like Kanban that provides a continuous, sustainable pace of development, without pausing for planning or demonstrations except on an as-needed basis. For these shops, the solution is even simpler:
Fix It Now
Our clients can’t get work done at all with our product, or their work is seriously impeded; put it at the top of the work queue.
Fix It Later
Our clients might have noticed a problem, but it can wait. Drop it in the queue wherever is appropriate.
Either way, it’s important to note that except in cases of extreme emergency, you shouldn’t sacrifice work in progress to fix a bug! You’ll pay all kinds of costs in quality and time. You’ll be better off if some team members work on the new problem, while others clear work in progress out of their way.
Important note on priority labels
If you follow a prioritization scheme like those laid out here, and you decide to use labels like P1, P2, and P3, or Critical, Important, and Unimportant, you may run into problems with clients (or account managers!) who don’t understand why all of their bugs aren’t P1/Critical. By using innocuous labels like +0 (fix it now), +1 (fix it next sprint), and +n (fix it later), you may be able to avoid this problem, at least for a while.