Is it a defect or an enhancement? The answer to this question makes a big difference to the software team. The developers are very much involved with the product that they are building and often times they take offense if a requirement defect or an enhancement (new functionality request) are mislabeled as defects, i.e., a problem with design or implementation.
The problem is, none of this matters to the business stakeholder. A good Agile team shouldn't even care about the difference between a bug, requirements defect or enhancement, as long as it is work that needs to be done. Clinging to categories is often a symptom of team division and dissension.
Monday, December 8, 2008
The business value of fixing defects
Less defects is always a good thing. Right? Not so fast. Fixing a defect has both benefits (more obvious) and costs (often easy to ignore). In this posting, I'll concentrate on some of the costs and why they can sometimes outweigh the benefits. This analysis is performed from the perspective that everything we do in a software project has to come in line with adding value to our stakeholders.
First, let's discuss the opportunity costs. Allocating resources to fixing a defect takes away from doing other things - such as fixing more important defects or implementing new features. The way to prevent misallocation of precious resources in an agile setting is to treat defects as any other quantity of work - create stories for them and, based on a prioritization exercise that takes into account feature stories, work them into the backlog. In a non agile setting, misallocation of resources due to high opportunity cost is trickier. Since prioritization is usually fractured between requirements and defects, defects usually get prioritized among themselves and get fixed within the allotted time. This usually leads to inefficiencies - since very seldomly the predetermined time for 'fixing bugs' is just right. Many times, teams will over fix some parts of the code and under fix others. There is also a temporal horizon bug fixing problem (I'll deal with that more in depth in a separate entry) - in brief, more recently discovered bugs tend to be fresher in people's minds, and thus, receive more attenting than older bugs.
Second, fixing bugs is risky. Touching a piece of code runs the risk of introducing more bugs, in other words, doing more harm than good. This risk should be managed by the project manager just as she would manage any other project risks. This is particularly heinous since time and attention for retesting are often in short supply.
To conclude, I'm not advocating against fixing defects. The point I'm making is that fixing defects should be treated as any other quantity of resource consuming endeavor, and as such, it should be balanced against other resource demands from the perspective of getting the most bang for the buck for the project stakeholders.
First, let's discuss the opportunity costs. Allocating resources to fixing a defect takes away from doing other things - such as fixing more important defects or implementing new features. The way to prevent misallocation of precious resources in an agile setting is to treat defects as any other quantity of work - create stories for them and, based on a prioritization exercise that takes into account feature stories, work them into the backlog. In a non agile setting, misallocation of resources due to high opportunity cost is trickier. Since prioritization is usually fractured between requirements and defects, defects usually get prioritized among themselves and get fixed within the allotted time. This usually leads to inefficiencies - since very seldomly the predetermined time for 'fixing bugs' is just right. Many times, teams will over fix some parts of the code and under fix others. There is also a temporal horizon bug fixing problem (I'll deal with that more in depth in a separate entry) - in brief, more recently discovered bugs tend to be fresher in people's minds, and thus, receive more attenting than older bugs.
Second, fixing bugs is risky. Touching a piece of code runs the risk of introducing more bugs, in other words, doing more harm than good. This risk should be managed by the project manager just as she would manage any other project risks. This is particularly heinous since time and attention for retesting are often in short supply.
To conclude, I'm not advocating against fixing defects. The point I'm making is that fixing defects should be treated as any other quantity of resource consuming endeavor, and as such, it should be balanced against other resource demands from the perspective of getting the most bang for the buck for the project stakeholders.
Subscribe to:
Comments (Atom)
