Agile defect management strategy

"We don't have any defects, so we don't need a defect management strategy".

If you are in that situation, you're fooling yourself. Good teams are not those who don't make any mistakes (that's an illusion!) - they catch their mistakes before any harm is done.

And for that, they have a defect management strategy in place. And that strategy must be continuously inspected and adapted.

The following is a high level outline for an initial agile defect management strategy:

Define: What is a defect?

There's nothing more cumbersome than the discussion whether something is a defect, "Works as designed" or a Change Request. And that discussion does not solve the problem at hand. It's a red herring. You do not want to decide this on a case-by-case basis.

  Align the team and all stakeholders on what you call a "defect" and how to define it. You are free to inspect+adapt the identification criteria frequently. But don't make ad-hoc decisions after getting enraged about individual reports.

How will you track defects?

It doesn't really matter whether you decide to use Post-It's, your Backlog tracking tool or a dedicated application lifecycle management suite. What matters is that you use appropriate means and everyone agrees on the approach.

Issues to consider are: Who needs the information, what will they do with it?

Separate: What is not a defect?

At least as important as the definition of defects is a clear definition of what will not be handled as a defect. This doesn't need to be very formal, specification by example does the job quite nicely.  Typically, issues that are not defects become stories in the Product Backlog and are at the whim of the Product Owner.    

 Some product owners will claim that "as long as it doesn't affect revenue, it's not a defect". We will not discuss here whether that is a good approach. It is merely one of many possible decisions in a project.

 Again, align the team and all stakeholders on what is not a defect and where the dividing line is.

Handle: How will you deal with defects?

It may be obvious to some, but it's not bad to have an open discussion. Depending on the formality and scope of the project, you may want to discuss topics such as severity, priority, SLA's etc. 

Furthermore, you should discuss how you will ensure that the issue is gone once and for all.

Improve: How will you deal with non-defects?

Just because it's a bug doesn't mean the software is doing great. Some "non-defects" are actually improvement suggestions. Others are distractions from the product vision. Yet others are simply a waste of time. While you will need to decide the next steps on a case-by-case basis, you should have a clear strategy on the next steps. After all, your purpose is not to clear the defect list, but to provide a great product that excites customers.

Flakiness: What if you don't know?

Bugs may also be flaky. You may need specific approaches for dealing with the "Bugfoot" (someone is adamant to have seen it, but there is no proof) or the "Heisenbug" (the nature of the bug changes by observing it). The worst thing you can do is sink near-infinite effort into analysis, but you also don't want to disappoint your customers. Claim the common ground.

Conclusion

Invest a bit of time to create a clear defect management strategy. Inspect and adapt your approach whenever necessary. Stay lean and pragmatic. Align.

This will make your agile project much more successful.