For waterfall projects, the classic defect curve is used to determine when a product is ready to ship. This is because most of the features have been “completed” during the first part of the development cycle, and the only work left to do is fixing the remaining defects. With Agile, there is a different approach where the work for the next iteration (2-4 weeks) is determined at the beginning of each iteration. This work should include taking the highest priority items from the backlog and working on those. In an idea environment, any defects are including the backlog and prioritized along with all of the features or enhancements to complete. However, when the defects are separated, the counts take on a life of their own.
These counts create perception issues and also cripple the Agile process because they are not prioritized with all the other work that is needed for the product. For instance, ten defects may cause one engineer to cringe, while a customer may not care about one thousand defects as long as the software performs its job. In addition, these defect lists have to continually be reviewed as a separate work set, which makes overall prioritization nearly impossible. In general, separating the software defects from the rest of the work is a relic of the waterfall days, while the Agile way is an all-encompassing backlog. When looking at a defect chart and waiting for the slope to point downwards, a good question to ask is “Why am I looking at a defect chart?”.
Continual Improvement 
With a green-fields project, a defect chart doesn’t make sense I agree. When transitioning from waterfall to agile, though, it seems a reasonable middle step. Of course, I think that the defects should be prioritized right along with the stories and given time in an iteration accordingly.
To me, the real magic of agile is really the prioritization. An agile team should be able to concentrate on just the most important things on their plate. Even if stories and features are split into two separately prioritized features, a solid product manager should be able to bring them together and keep the team focused. A weak project manager, though, is the kiss of death for even a strong agile team.
I agree with the transition situation, but a transition situation can quickly become status quo and linger for years. Even with a great project manager, a long list of defects can cloud the perception of the quality, which can lead to other issues within the organization. I’ve heard this explained as internal quality versus external quality, and it seems to make sense. Engineers often confuse the two, when what’s important to the customer is external quality.
[…] Continual Improvement » Blog Archive » Counting software defects When looking at a defect chart and waiting for the slope to point downwards, a good question to ask is “Why am I looking at a defect chart?â€. (tags: defects agile lunt) […]