No bugs in agile?!?

When a team is following an agile delivery approach and they have developed a Definition of Done (DoD) containing one or more criteria indicating that no defects are permitted in or as an outcome of completed work items, they should not have to deal with bugs escaping a sprint, and hence, the practice of documenting defects should become obsolete.

But how often does this happen in the real world?

Let’s consider what’s required to achieve this:

• Pairs programming or other quality-focused development practices
• Dedicated test environments covering the totality of the solution including all points of integration
• Full coverage automated regression testing
• Frequent (if not continuous) integration and deployment to support the progressive testing of completed requirements
• The planning, definition and automation of test cases covering all of the requirements being worked on in the sprint
• The ability to execute full non-functional testing within each sprint – security, performance, accessibility and localization to name just a few

If any of the items in the preceding list look daunting in your current context, don’t panic – you are not alone.

Teams in organizations early or midway through agile transformation will work on products possessing none, some or all of the above prerequisites.

In the interim, here are three choices for those teams:

1. If the defect relates to the natural evolution of the customer’s wants and needs then it should be captured as a new requirement in the product backlog and prioritized by the Product Owner.
2. If the defect can be resolved and properly re-tested within the current sprint, there is almost no value in documenting it. If there are significant time zone or geographic boundaries separating development and test roles, or if either the developer or tester are unable to work on it right away, the defect might still need to be captured somewhere to ensure it doesn’t fall through the cracks before the end of the current sprint.
3. If the team’s DoD excludes the resolution of cosmetic or low severity defects, the defect should be added to the product backlog and prioritized by the Product Owner. This is an acceptable compromise for many lower maturity teams, but over time as their delivery capability improves, they will want to tighten up their DoD to prevent a progressive increase in this specific type of technical debt and to avoid their customer experiencing Death by a Thousand (quality) Cuts.

Linus Torvalds said it best “I’m generally a very pragmatic person: that which works, works.”