In my experience, “defects” actually fall into two categories. The first group represents things that work exactly as we designed them to work, but that people feel don’t work correctly. In other words, they aren’t broken, they just aren’t very good. These actually aren’t defects at all; they are poorly designed features. They should be captured and added to the list of things we need to do. Whoever owns the “to-do” lists (enhancements, new ideas, product roadmap) should add these improvements to the list. Generally, that’s product management. Those items need to be analyzed, reviewed and prioritized along with everything else on the list.
The second kind of defect is one where the product doesn’t work as designed. In other words, it is broken. If it adds a column of numbers and gets the wrong result, that is a defect. In those cases, these items shouldn’t have to get in line or be analyzed or prioritized. They should be fixed. Development should own these, assess how the defect happened and fix it as soon as possible. Once that’s completed, product management should be involved in deciding when to deliver a fix to the market.
One more comment: If the second type of defect is a common occurrence, it could be a quality issue. Usually, quality is a policy issue, a function of management policy and standards. Some companies have a zero defect policy, resulting in high-cost—and sometimes much slower—development processes. Others choose lower costs or quicker delivery as a policy objective, sometimes resulting in quality issues. Should you start to see a growing number of defects, it may be time to look more closely at your policies.
