Thinking in terms of the BA and the Developer.

1. ENHANCEMENTS:
BA: “Oops, I forgot something we need”
Dev: “Ok, lets write it up, prioritize it, and put an estimate around it. Then we can decide if we need to put it in this iteration and pull something else out”

2. FUNCTIONAL DEFECTS
Dev: “Oops, I forgot to do something that was specified” or “There was a misunderstanding about the requirements”
BA: “Ok, do you have any more questions? Let’s look at the requirements, review the estimate, and see where we should put this” (and also see what we can do to make this kind of requirement clearer in the future)

3. TECHNICAL DEFECTS
Dev. “The code isn’t working under this one condition, and I don’t know why” (and I can’t give you a good estimate of how long it will take to fix, but we can allocate a block of time and monitor how its going)
BA: “Ok, why don’t you dive into it for a bit, and get back to me in an hour with a ‘best-guess’ estimate for what it would take to fix it. From there we can decide to plug away at this one, or work on a higher priority issue”

The point of my blog post was that the first two are really communication and requirements management issues, and once those requirements are discovered, can be handled in the same process as normal features including: tying the feature back to user goals, and the same completeness of UI design, acceptance tests, etc.

TECHNICAL DEFECTS, are what I consider true bugs, and they should be managed at the source, and covered with tests. (you do write a test to reproduce the bug, then make the test pass proving that you’ve fixed the bug, right?)

If there was a bug tracking system filled with items of all three of these types, it would make sense to go through and pull out the first 2 types and move them to the normal product backlog, leaving only TECHNICAL DEFECTS left.

Now this is where a ‘zero-bug policy’ can become a reality. If the only kinds of bugs that are in the tracking system, are based on actual requirements that the developer tried to implement but had an issue, and those stories were scheduled and prioritized ahead of whatever we are working on now, it stands to reason that resolving the defects for prior stories is critical, and those issues should be resolved asap, and we should be working towards getting rid of them all.

Once you’ve cleaned out the bug tracking system to have only true defects and not new requirements, its basically a list of “things you said you finished but didn’t”, and the entire team is very motivated to come together to clean them all out. Its one of the single best ways to bring a team together that I’ve ever experienced, and I hope you get a chance to try it out.
-John

I remember being extremely stressed out and frustrated as we continued to put more and more time into an ever growing and ever changing list of features that weren’t really valuable to the user. The scope wasn’t well managed, and the way that bugs were handled fed into that, but once we started to properly categorize them, things started to get better. A big part of it came from the Zero-Bug policy, because it quickly highlighted bugs that were not classified properly. I know I felt really good when we had no bugs in our queue.