I rode up to Redmond with Jeffrey Palermo this morning and had a great talk about defects. Jeff asserts that a project can and *should* have zero defects. Playing devil's advocate a bit, I challenged this assertion by asking him to define a defect.
His answer was a good one. A defect is basically a violation of the contract between the product owner and team/developer as to what the condition for satisfaction or agreed upon definition of done is. I am paraphrasing a bit here, but I think he is spot on.
As developers, we tend to place so much focus on defects/bugs that we create databases in which to store them! We build these virtual backlogs to go through and comb over and we even encumber the product owner to help us prioritize them (yes, even very effective agile teams use defect/bug tracking databases). From Jeff's perspective, this is nonsense, because a story/feature is not done until we/you have fulfilled the contract between the product owner and team. If you have a defect, the story/feature isn't done. If the story/defect is not complete, then you get ZERO credit for it. Marking the story as "done" and leaving some defects behind is a violation of the definition of done, and now, you have a database to prove it!
So what do you do? If the story/feature isn't done, it stays on the product backlog. Of course, the product owner is in control of the ensuring that the feature/story meets his/her requirements, and just as requirements can and will change, so too can the contract. This doesn't mean that you manipulate the product owner to bend to your will (or laziness). This is where open, collaborative and trustworthy communication comes into play.
It is perfectly acceptable to re-estimate a feature or story within a sprint. I may learn through discovery that a feature/story that was a "5" (hours, points, whatever), is actually an 11. The product owner, given this information in a timely manner, can decide to further decompose the feature/story or defer/drop a feature/story from the sprint in order to make the re-estimated feature/story.
The key is that the product owner should never be surprised. If you wait until demo/retrospective time, and you missed a commitment, it's too late. Talk to your product owner early and often, partner with your product owner so that you can make decisions jointly. If you do so, defects should virtually go away.
One of the most cherished capstones you can reach as a consultant is that of a trusted advisor. You build trust with your clients/sponsors/product owners by always being honest and transparent, and at the same time, being flexible. This does not in any way guarantee that your client will ever love bad news, but open, honest, yet flexible partnerships go both ways, which in turn leads to flexibility on the part of the client. This is a winning combination for consistently meeting commitments, or at the very least ensuring that your client is never surprised.