Experience of Customer Impact as Defect Rating Value
Customer Impact as Defect Importance
The usage of the two defect tracking fields severity and priority is widespread and dominant in defect management circles. But there is a number of problems with these attributes – they allow for ambiguity and they two fields do not focus on what is truly important – customer satisfaction. Let’s face it – without customer satisfaction we are out of business pretty fast.
Thus to focus on what is important we have chosen to reflect what is important the defects impact on the customer. But you might say that not all of our systems have a customer! Well think twice – in the case where your systems don’t have an obvious end customer (player/operator/support/…) the component is a part of a producer-consumer chain. Your component allows for some other software module to provide functionality and there you are – you do have a customer!
To reflect the impact on the customer we have chosen the following five states:
• Catastrophic
If this issue isn’t resolved ASAP customers will go elsewhere
• Major
The defect is seriously disturbing for the customers using the product
• Noticeable
Annoying for customers using this product but not on its own right a reason to leave
• Minor
Barely noticeable for the average customer and non restrictive for the customer
Every piece of software has some sort of customer, if not – Stop what’s developed now!
The customer could be the actual end player, an operator, another software component, test or technical requirements. If we do not refactor this piece of software we will not be able to do in the future i.e. the company itself is the customer.
Customer Impact vs. Severity and Priority
Priority and Severity fields are supposed to inform us how severe a defect is in terms of the customer, testing, urgency and so forth. This is important information that does describe the situation but not to the point according if you ask me. As an example consider a spelling error in the client. What Severity does the defect deserve? Using the standard approach I’d say that the severity would be minor or even neglectable because the defect won’t make the system crash or even hinder the customer to use the full scope of functionality. But it does have a very huge impact on the customer’s perception of the company’s quality and trustworthiness. So from a business perspective the defect is important. Severity doesn’t allow us to express that properly. So to resolve this – the Priority attribute enters the field of play so that product management can describe their urgency to get the issue fixed. If this issue would have been described with Customer Impact the state would have been Critical or even Catastrophic depending on the spelling error.
Another equivalent example would be a system that crashes every Friday the 13th every 12th month. By definition it would get Severity Catastrophic but what is the Priority? If this issue would have been described with Customer Impact the state would most likely be Minor.
It is in such cases as described above we get struck in the face by ambiguity – we have an issue with low minor severity and Critical or even Catastrophic priority. What are we supposed to do with it? It is for such reasons wars can be started! People dig themselves down in trenches defending their positions loosing focus on what is important – Customer Impact!
Yet another motivation to move away from the ambiguous Severity & Priority notation is that it is close to impossible to make some general rules for how long a defect can be left untreated. If one talk about Customer Impact it is pretty obvious that Catastrophic has to be dealt with as soon as possible.
The usage of the two defect tracking fields severity and priority is widespread and dominant in defect management circles. But there is a number of problems with these attributes – they allow for ambiguity and they two fields do not focus on what is truly important – customer satisfaction. Let’s face it – without customer satisfaction we are out of business pretty fast.
Thus to focus on what is important we have chosen to reflect what is important the defects impact on the customer. But you might say that not all of our systems have a customer! Well think twice – in the case where your systems don’t have an obvious end customer (player/operator/support/…) the component is a part of a producer-consumer chain. Your component allows for some other software module to provide functionality and there you are – you do have a customer!
To reflect the impact on the customer we have chosen the following five states:
• Catastrophic
If this issue isn’t resolved ASAP customers will go elsewhere
• Major
The defect is seriously disturbing for the customers using the product
• Noticeable
Annoying for customers using this product but not on its own right a reason to leave
• Minor
Barely noticeable for the average customer and non restrictive for the customer
Every piece of software has some sort of customer, if not – Stop what’s developed now!
The customer could be the actual end player, an operator, another software component, test or technical requirements. If we do not refactor this piece of software we will not be able to do
Customer Impact vs. Severity and Priority
Priority and Severity fields are supposed to inform us how severe a defect is in terms of the customer, testing, urgency and so forth. This is important information that does describe the situation but not to the point according if you ask me. As an example consider a spelling error in the client. What Severity does the defect deserve? Using the standard approach I’d say that the severity would be minor or even neglectable because the defect won’t make the system crash or even hinder the customer to use the full scope of functionality. But it does have a very huge impact on the customer’s perception of the company’s quality and trustworthiness. So from a business perspective the defect is important. Severity doesn’t allow us to express that properly. So to resolve this – the Priority attribute enters the field of play so that product management can describe their urgency to get the issue fixed. If this issue would have been described with Customer Impact the state would have been Critical or even Catastrophic depending on the spelling error.
Another equivalent example would be a system that crashes every Friday the 13th every 12th month. By definition it would get Severity Catastrophic but what is the Priority? If this issue would have been described with Customer Impact the state would most likely be Minor.
It is in such cases as described above we get struck in the face by ambiguity – we have an issue with low minor severity and Critical or even Catastrophic priority. What are we supposed to do with it? It is for such reasons wars can be started! People dig themselves down in trenches defending their positions loosing focus on what is important – Customer Impact!
Yet another motivation to move away from the ambiguous Severity & Priority notation is that it is close to impossible to make some general rules for how long a defect can be left untreated. If one talk about Customer Impact it is pretty obvious that Catastrophic has to be dealt with as soon as possible.
Comments