How to prioritise defects or bugs
In my previous article of Software Maintenance I talked about Corrective and Preventive Maintenance. Corrective and Preventive Maintenance are distinguishable by the time a defect is discovered. Preventive Maintenance is before the service to end-users is affected by a defect. Corrective Maintenance is after the software is taken into production. Today I like to continue on this subject by looking further into Corrective and Preventive Maintenance on how to prioritise defects on which are the most important.
What is a defect or bug anyway?
In the previous article we said:
A defect is the situation that the software doesn’t meet the customers’ functional or non-functional requirements or is not documented accordingly. What results in the service to the end users is not fully delivered.
If you look closer at a defect, you see it has one of the following characteristics:
- Incorrect functional behaviour or faulty results of the software
- Flaws in performance, security, safety or other quality requirement
- Semantic flaws (like unclear messages to the user)
- Errors (even typos) in Software Documentation
These characteristics have different impact and lead to different priorities and actions to fix these errors. Sometimes a defect is even beyond repair.
What about service impact and priority?
What is service impact?
Based on the characteristics above a defect has a level of impact of service. A typo in software documentation has less impact then a “this website is not available“ message on a site like Amazon.
By determining the impact level it’s possible to rank defects based on services that are disrupted. Usual impact levels are: low, medium, high and critical. The criteria of the impact are defined most of the time in Service Level Agreements.
The table below gives an indication of service impacts:
| Critical | Critical business processes are not working anymore or over 50% of all users of the software are affected by the disrupted service. |
| High | Critical business processes are working, but with a degraded function or performance or over 10% of all users of the software are affected by the disrupted service. |
| Medium | A few users are affected by the disrupted service of the software. |
| Low | A single user is affected by the disrupted service or it’s outside agreed operating service times. |
Service impact alone is not enough to decide if a defect should be fixed immediately or not. It’s also based on urgency.
What is urgent?
If you ask this to the one having a problem, he always says his problem is the most urgent one on the world and he wants to fix it by yesterday. Luckily we can define several levels of urgency.
| Immediate / Top | In this case the reputation of the business is at stake or vital business processes are down and no workaround is available. The focus here is to restore the situation to the last working state. |
| High | In this case there is a workaround available, but this workaround is very complex. The disrupted service has severe financial implications. |
| Medium | All vital business processes are up and running. One or more features are not working properly. The workaround that is available is risky or costs a lot of effort. |
| Low | There is a simple workaround available. The customer can do its work almost without any extra effort. Another possibility is that the failover service is in place. |
So what is the highest priority than?
Ok, what we can do now is the following. We can add the service impact and urgency to the defects. After that we can assign a priority to the defects based on the following table.
| Urgency vs Service Impact | Critical | High | Medium | Low |
| Immediate | 1 | 2 | 3 | 4 |
| High | 2 | 3 | 3 | 4 |
| Medium | 3 | 3 | 4 | 5 |
| Low | 4 | 4 | 5 | 6 |
In the end you sort the list of defects ascending on priority. There you got it, a list with the highest priority on top! After all these steps we covered all the defects that are discovered in a production environment, which means we only covered the Corrective Maintenance part. If a defect is discovered in preproduction phase, you probably like to fix that before the new version is installed in the production environment.
This makes we need another way to rank defects on priority. That’s where severity pops up.
What about severity?
Severity is the classification of impact level the defect has on the software. It could be on development or operation of the software. The classification is comparable with the service impact I wrote about earlier.
This means that when we relate the severity classification to urgency, we have the priority.
Commonly used classifications are:
| Critical | In this case: very important functionality of the software is not working; or installing the software into the production environment is not possible. No workaround is available. |
| High | Very important functionality of the software is not working. A workaround is available, but using the workaround is time-consuming, risky or difficult to do. |
| Medium | All vital functions are working. The defect has a simple workaround, like using another option to do the same thing or instruct the users how to interpret the given response of the software. |
| Low | In this case no workaround is necessary. The software is working properly. Defects in this classification are mostly inconvenient for the user. Things like improper layout, annoying pop-ups or semantic errors. |
If you do this for all defects and you order the list ascending on priority, you have all the defects prioritised.
Is the defect worth fixing?
Now we know how to prioritise defects, there is one question left. Is the defect worth fixing? As I wrote earlier there are cases a defect is beyond repair.
If you start to analyse the defect you get an idea of the amount of work or effort is needed to fix the defect. The rule of thumb here is: If the costs of fixing the defect is more expensive or equal to the costs of leaving the defect in, you probably shouldn’t fix it or find another solution.
Another solution could be disabling the functionality in total or apply a shortcut as fix. The last option doesn’t fix the problem, but it keeps the software available for use while you need to find another solution or replacement of the software.