During the daily business I have seen bug assessments with different tools and in different projects. Although the tools and projects were very different, the bug assessment was always the same. Bugs were rated in a technical way with view on their technical impact. But we don’t fix bugs for technical reasons. We fix bugs to have satisfied customers. So why don’t we respect this fact during bug assessments?

Within this article I want to show an alternative way to rate bugs. It is based on the customer benefit and the costs of the bug fix.

 
Actual situation

As mentioned before, bug assessments are done with focus on technical criteria’s. Most issue trackers offer the following parameters to rate a bug and therefore most bug assessments are focused on these parameters:

 
Severity

The severity is often the most important rating parameter and it is unfortunately a purely technical criteria in most projects I seen so far. The bug will be rated based on his technical impact. So it could be a trivial issue like a misspelled word, a minor issue with minor loss of functionality, a major issue like a crash in special cases or a blocking issue which blocks further development and testing or the productive use of the software.

 
Priority

This parameter describes the significance of an issue compared with other issues. This is a very critical parameter because the rating is often based on the person or the team which does the rating. Therefore you should define clear definitions for the priority. At the end, the rating must be done based on clear rules and not based on a personal opinion. For example you may define the following scale: low, medium and high where high means fix immediately, medium means fix before the next release and low means fix if there is time left or defer the bug fix to a future release.

 
Critical

Some projects also use an additional parameter which shows whether the bug is critical or not. A critical bug may be for example something which could result in an injury for the user or some other critical situations or wrong results with bad effects to a person. Critical bugs must be fixed first. So this parameter is not really needed necessary because you can simply use a priority level “critical”. But nevertheless in some projects this parameter is used to show the relevance of critical issues.

 
Feature development vs. bug fixing

Your projects should always be focused on the customer benefit. For example if you plan a sprint and the respective features to implement, you do this because you want to create customer benefit. As feature development has this focus the bug fixing should have it to! Bug fixing is nearly the same as feature development. You develop a functionality based on existing code or maybe you write new code.

But in most project’s you will see that feature development and bug fixing are treated different. Look at you own projects and compare the following: who rates the importance, plans the development and looks at the results of feature development and bug fixing? You will often see that there are two very different processes for these two kinds of work. Feature development is customer driven with respect to customer benefits and bug fixing is driven by the development team with respect to technical criteria’s. So in the daily business we use two very different processes although the two kinds of work have (nearly) no difference, neither in their goals nor their execution.

 
A possible new procedure

As feature development and bug fixing should be executed with the same process, you have to adapt the actual bug assessment procedure. Features are rated or prioritized by the customer benefit and by the development effort. So do the same for bugs. Rate the customer benefit and the effort. The parameters for a bug assessment should therefore be:

 
Customer benefit

Use the same scale like you use for features. Maybe in you feature planning you call it “priority” instead of “customer benefit” but the priority of features is hopefully based on the customer benefit.

 
Effort

Use the same scale or method like you use for features. So for example work with effort in days, with function points ore some scale like low to high.

 
Critical

This additional parameter may be used or not, for the same reasons like shown in the “actual situation” description.

 
Example

Let’s have a look at a typical example: an error message which is not user friendly. In this example scenario the customer works with software used to execute a process which involves the need of several technical devices. At the start of the software it will check whether all devices are connected. If a device is not connected a message will be shown: “Unable to connect to the device. Please check whether it is turned on.”

Unfortunately the error message does not say which device is not responding. So the user has to check every single one. Of course this unnecessary procedure is very frustrating for the user, especially if this happen once in a while. So he summits a bug report.

As you receive this bug report you have to do an assessment. Let’s start with the classical approach: The software project leader will do an assessment based on the severity and the priority parameter. From his technical point of view he decides: Severity is low because there is no loss of functionality and it is a little text improvement only. And priority is also low because compared to other bugs this little text improvement is not important. As a result of this assessment the bug will maybe never get fixed or it will take a long time.

What will change if we do the bug assessment in the same way like feature assessment? In this case the bug rating will be done by the product owner (the person with the project responsibility). He represents the customer and has to do time and cost management. So he will rate features and bugs according to customer benefit and costs. As he rates the bug he will maybe set the customer benefit to medium or even high and the costs to low. In combination of these two ratings the bug fix has a high possibility to get fixed in the next release (depending on the other open tasks).

I think this changed bug assessment process will have a high impact on your customer satisfaction and on the product quality. Especially such little issues, which sometimes can be fixed in minutes, will have a high value for the user. And unfortunately with the normal assessment procedure they stay open for a long time. Furthermore, the times spend for assessment and re-assessment during this life cycle of the bug will often be higher than the time needed for the bug fix.

 
Summary

There should be no difference between feature planning and bug fix planning. Therefore use the same parameters to assess features and bugs and use the same process for both kinds of work. And of course, planning of features and bug fixes should also be done by the same persons.