Defects in the Agile World – Four Key Questions (Part 3)

Each of the three questions addressed in my previous posts (Part 1 and Part 2) examines defects from a different perspective, and they all should be considered collectively when making a judgment call on a defect. A couple of additional questions should also be addressed when implementing such a hybrid solution:

Do We Size Defects in the Backlog?

If the defect is to be added to the backlog, then, given it is now a PBI, it should be sized. Mike Cohn, a leading Agile coach, recommends sizing defects similar to what we do for user stories. This has two advantages. First, the velocity will more accurately report the work done by the Scrum Development Team. Second, this leads to a better defect management in instances where the team has a significant defect load (e.g. legacy or operation/maintenance type defects).

Do We Create a Separate Backlog for Defects?

From a Scrum perspective, the answer is No. As mentioned earlier, the defects should be treated as PBIs. They should be owned, prioritized, sized, and signed off by the Product Owner. Having one Backlog would ensure that the team’s focus is on one place only.

Be mindful of the Agile principles

Whichever process you decide best fits your team, always be mindful of the 12 Agile principles.

The following principles are of particular interest to this defect management discussion:

• Simplicity – Keep the defect management process to a minimum. If you find your team over-managing defects, bring up some probing questions to refocus the team on the main goal, delivering value: Why do we need to report defects? Who is benefiting from the process? What’s the value in implementing such an elaborate process?
• Technical Excellence – Again and again, the team’s focus should be on delivering working software through technical excellence. Ideally, that would mean zero defects. Realistically, it’s often not the case. Teams usually struggle with a high volume of defects. If you happen to be on such a team, you might find it more efficient to address the reasons for this issue, instead of putting an elaborate defect management process in place. Maybe the team needs better coding standards? More technical training? Or a better understanding of the acceptance criteria?
• Self Reflection, Tuning, and Adjustment – One of the most valuable characteristics of an Agile mindset is promoting self-reflection. By bringing up the questions and discussions mentioned above to the Retrospective meeting, the team will have a chance to inspect their defect management processes and tools, and adjust them as necessary.

Overall, the good practices discussed here should be looked at as a guiding tool. Try them, see how they work, and inspect and adapt when needed. Be Agile!

References & Further Readings:

Handling Bugs in an Agile Context

Coping with Bugs on an Agile/Scrum Project

Keeping Agile with Zero-Bug/Defect Policy

Should Story Points Be Assigned to a Bug Fixing Story?

Dealing with Bugs in the Product Backlog