Defect versus Incident - what is the difference and why does it matter? defect management
Some people say Defect and some say Incident. Both are correct, but what is the difference and why does it matter? In this article I will explain how I see the difference, why it matters and perhaps more importantly when it matters.
When it comes to defects, then we have already defined that a defect is when the solution does not fit the requirement. We also defined what a defect is not, so we should be fine with just the term defect. Right? Well, there are actually a few reasons why we should actually have have two different definitions for a defect.
The Legal Aspect
One of the least understood aspect of defects is the fact that there is a point in the development process that change the way we manage defects. That point is when a solution is accepted, which occur during the acceptance phase before code is deployed and released in production. From a legal perspective this is when the standard agreement between the client and the provider is fulfilled.
There might be additional services added beside the standard agreement that add another layer on top of the standard one, like a post go live support period or extended defect management after release.
This point in the development is also where responsibilities sometimes shift from the development team to a maintenance team for example.
The Complexity Aspect
Another important aspect is the complexity aspect that comes into play as the deploy is released into a production system. Even if the pre-prod environment is identical to the production environment it is still withing the development teams responsibility. Once put into production this usually changes and the complexity with the full solution as well as the full network make it a much more costly affair to manage problems.
When issues occur in the development teams environments it rarely involve other teams. Problem are managed within the team with the occasional support from surrounding system teams or network teams. Once you go to production however problems often become the affair of many teams.
The Workflow Aspect
How the team work with a defect is not the same for something found in a production environment, for obvious reasons. In a normal development workflow you can choose what code go to production, but for a defect found in production you do not have that choice. This is why you bypass the normal workflow and use hotfix, which is a fast track to correct problems in production environments.
Two ways of working, two types of defects
Based on the fact that we do have different processes for a defect found in production and for a defect found in the lower environments we should separate the issues themselves. This is not just to make it easier to identify in for example Jira, but also since there can be differences in who will manage the defect and the process to manage the defect itself. It also allow us to define the defects differently.
Defects are problems that prevent acceptance.
If there is a defect, then acceptance should not be given. It is a problem that only affect the legal aspects of an agreement. It can cause delays, which in turn can damage the company financially, but it will not affect the end user as it has never been released. By definition a defect is considered an internal problem and solving it involve only the development team within the standard way of workflow. It is simply development not yet complete.
The severity of a defect determine when in time it should be fixed based on dependencies withing the project as well as surrounding systems.
Defects are considered free since they are part of the development agreement.
In Jira a defect is placed inside a development to block it from going into production.
Incidents are problems that can damage the company.
An incident found in production is available to end user and as such it can cause damage to the company. It can cause disruption of service, it can damage the brand perception or even cause direct impact on sales. Solving this problem often involve multiple teams and it require a separate workflow that disrupt the standard workflow. By definition this is an external problem and it can cause legal issues as it is found after acceptance has been given.
The severity of the incident determine when in time it should be fixed based on the damage it causes.
Incidents always comes with a cost, which usually is some form of support or maintenance agreement.
In Jira an incident is a standalone issue that is handled as development task.
This is my way of defining the differences between a defect and an incident. I have found that by making this distinction I can design better workflows in Jira that make incidents more visible. I can also use this in Jira Service Desk and other systems and by separating the two types I am not limiting the different workflows and I do not have to bloat the workflow by combining the two into one.
Do you agree with my definition?
When it comes to defects, then we have already defined that a defect is when the solution does not fit the requirement. We also defined what a defect is not, so we should be fine with just the term defect. Right? Well, there are actually a few reasons why we should actually have have two different definitions for a defect.
The Legal Aspect
One of the least understood aspect of defects is the fact that there is a point in the development process that change the way we manage defects. That point is when a solution is accepted, which occur during the acceptance phase before code is deployed and released in production. From a legal perspective this is when the standard agreement between the client and the provider is fulfilled.
There might be additional services added beside the standard agreement that add another layer on top of the standard one, like a post go live support period or extended defect management after release.
This point in the development is also where responsibilities sometimes shift from the development team to a maintenance team for example.
The Complexity Aspect
Another important aspect is the complexity aspect that comes into play as the deploy is released into a production system. Even if the pre-prod environment is identical to the production environment it is still withing the development teams responsibility. Once put into production this usually changes and the complexity with the full solution as well as the full network make it a much more costly affair to manage problems.
When issues occur in the development teams environments it rarely involve other teams. Problem are managed within the team with the occasional support from surrounding system teams or network teams. Once you go to production however problems often become the affair of many teams.
The Workflow Aspect
How the team work with a defect is not the same for something found in a production environment, for obvious reasons. In a normal development workflow you can choose what code go to production, but for a defect found in production you do not have that choice. This is why you bypass the normal workflow and use hotfix, which is a fast track to correct problems in production environments.
Two ways of working, two types of defects
Based on the fact that we do have different processes for a defect found in production and for a defect found in the lower environments we should separate the issues themselves. This is not just to make it easier to identify in for example Jira, but also since there can be differences in who will manage the defect and the process to manage the defect itself. It also allow us to define the defects differently.
Defects are problems that prevent acceptance.
If there is a defect, then acceptance should not be given. It is a problem that only affect the legal aspects of an agreement. It can cause delays, which in turn can damage the company financially, but it will not affect the end user as it has never been released. By definition a defect is considered an internal problem and solving it involve only the development team within the standard way of workflow. It is simply development not yet complete.
The severity of a defect determine when in time it should be fixed based on dependencies withing the project as well as surrounding systems.
Defects are considered free since they are part of the development agreement.
In Jira a defect is placed inside a development to block it from going into production.
Incidents are problems that can damage the company.
An incident found in production is available to end user and as such it can cause damage to the company. It can cause disruption of service, it can damage the brand perception or even cause direct impact on sales. Solving this problem often involve multiple teams and it require a separate workflow that disrupt the standard workflow. By definition this is an external problem and it can cause legal issues as it is found after acceptance has been given.
The severity of the incident determine when in time it should be fixed based on the damage it causes.
Incidents always comes with a cost, which usually is some form of support or maintenance agreement.
In Jira an incident is a standalone issue that is handled as development task.
This is my way of defining the differences between a defect and an incident. I have found that by making this distinction I can design better workflows in Jira that make incidents more visible. I can also use this in Jira Service Desk and other systems and by separating the two types I am not limiting the different workflows and I do not have to bloat the workflow by combining the two into one.
Do you agree with my definition?
