HOW Defects Are Managed in the Agile World The previous post addresses the defect types, their importance, and their ownership by answering the WHAT, WHY, and WHO questions. The next step is to draw an overall picture on HOW should the process work when examining defects in the Agile (and more specifically the Scrum) world. When […]
The previous post addresses the defect types, their importance, and their ownership by answering the WHAT, WHY, and WHO questions. The next step is to draw an overall picture on HOW should the process work when examining defects in the Agile (and more specifically the Scrum) world.
When discussing defect management in Agile, Agile advocates seem to come back with two main answers.
The first argument is that defects should not be “managed” but rather fixed instantaneously to keep up with the zero-defect mindset. Ideally, the team will be working closely together to tackle any defects found on the fly. This approach has the advantage of having low defects, and of being simple to implement without relying on too many processes and tools. However, it can cause Product Backlog Items (PBIs) to take longer to get Done, and would decrease the Velocity of the team, which might be (wrongfully) interpreted as inefficiency.
The second argument is that defects should be treated as user stories, managed in the Product Backlog, and prioritized by the Product Owner. The reasoning here is that defects should be ranked along with other items in the Backlog (user stories, spikes…). The Product Owner will decide which PBIs are high priority, regardless of their type. This process will ensure that the team is truly working on the highest priority items first.
A hybrid combination seems to be the most acclaimed by Agile practitioners: some defects are fixed on the spot, others would be carried to the Product Backlog and treated as PBIs. To determine which defect follows which path, you would need to answer these three questions:
If it is found while the Scrum Development Team is working on a PBI, and before it is marked as Done or released to production, then the team should address it during that Iteration, without creating a separate defect entry for it. If it is found after the PBI is Done or after it is released to production, then the defect should be treated as a new PBI item. In the former case, the team should not question the semantics (e.g. user story vs. defect) and rather just mark the defect as a PBI.
If a defect is truly urgent, then it should be fixed right way, otherwise, it could be handled as a separate PBI. Another way to ask this question is: Would the Product Owner sign off on the PBI, without fixing the defect? Which leads us to the third question:
Often times, teams find it helpful to include in their Definition of Done a specific criterion related to defects for a PBI. For example, a PBI cannot be marked as Done if it has Defects of priority Medium or above.
To be continued with answers to more questions…
Whether your budget is based on the fiscal year, the school year, or the calendar...
It’s well over halfway through the year, and if you’re like most people, you set a fitness goal. Have you stuck to it? We know how hard it...