—Root cause analysis for defects is critical for improving your process.
I’m in the process of changing defect management in my team. We use our retrospective to review defect and cost overruns during the sprint.
The change I’m making incorporates two ideas:
The first idea ensures the retrospective remains a safe place to acknowledge errors. This is important because the errors that prompted the defect could be the result of an error made by someone at the retrospective. For example, a coding error that escaped code review.
The second idea ensures we focus on root cause and not the defect correction. This is important because the defect is a symptom. First, focusing on the correction would repeat the code review. Second, this sets up the context so that the focus is on what was being attempted when the defect was introduced.
I focus on the code because that’s closer to where the error manifests. Defects manifest as a behavioural or functional issue because something isn’t meeting the expectation of “working”. Since we have a patch for the defect we have a notion of what expected behaviour is. What we don’t know is where the problem entered the lifecycle.
I could focus on the test but it seems obvious we lack a test case otherwise the defect would have been corrected earlier. Clearly, a lifecycle issue that manifests in requirements won’t have a test case…
Since the code is the focus I use the commit history as the starting point.
R3 <- defect fix applied to great new feature R2 <- another great new feature R1 <- great new feature
The patch applied in R3 might update changes in R2, R1 or both.
What motivated R3 is interesting. What motivated R3 is in R1 or R2 or both.
That is R3 might:
The problem gets complicated when there are many revisions affected by the defect fix. Such situations will bring in multiple people and perspectives. And hopefully ways to mitigate recurrence.