Bugs in Agile
I would like to state again that "any agile project should not have much open defects". Let me explain this a little more.
First, the reason for not keeping defects open has several reasons. The first kind-of obvious reason is that the longer it stays open, the more it costs to fix. This is mainly because the developer has moved on to other things and it's not "fresh" in his mind. The second reason is feedback which I come back later. The third reason for this is IMHO somewhat more important to understand. One of the key points of Scrum and iterative development is the ability to reprioritize and respond to the market, every month. This can be done because every sprint delivers "done" functionality. When software is kept in such a state then whenever the product owner says: "ship it!" then it ought to be shippable. Yes, there are some things (delivery stuff) that need might not be done, but they sort-of take a "fixed time". Bugs from earlier iterations, however, are UNDONE work. A bug means the work was not finished. A bug backlog means a list of functionality that was not implemented yet because something needs to be done. This means that there is a unknown-size buffer in the project, which makes the project not flexible or, if you wish, not agile in the exact meaning of the word. Having open bugs gives the product owner a fake sense of progress, an illusions. It moves the project back in waterfall. There will need to be awful bug-fixing periods at the end of the release. Same as previous panic.
Thus, having open bugs is a bad sign for an agile project and suggests that they are either back in some kind of waterfall or will fall back into it in the future when they are closer to release. (At least they will break the sustainable pace).
Someone pointed out, correctly, that it's very difficult to actually make no defects. Especially in "traditional" development. So how can this then have changed? Well, there are a few agile practices which allow for faster learning cycles and thus should make it possible to reduce bugs to, at least almost, zero. The most obvious one is, of course, iterative development with retrospectives. If you have 10 bugs at the end of an iteration, does your team ask: Why do we have 10 bugs open. Which means: Why do we have undone work. Which means: Why have we not finished one month of work in our estimate. Teams that are answering this question every month, or better, every 2 weeks SHOULD make improvements in their ways of development rapidly. If not then they do not use the feedback information that iterative development provides them.
Next to this basic practice, agile development promotes some "engineering practices" which ought to create a capability within the development teams to create bug-free software. Continuous integration for giving quick feedback on synchronization issues and showing the current status. TDD for the personal development cycle and working to high levels of regression test. Pair programming for constant reviewing. A-TDD for bringing in functional and system testing and letting them work together with development on the same functionality in the same iteration. Refactoring to keep you fast and clean.
Thus: "A project with a big open bug list is not an agile project"
