Finally the last question from our Agile Metrics Webinar. This question pertains to Rework From Defects.
Q: Is Defect rework allocation = similar to root cause type mark up in defects after fix?
A: Yes! We use a different terminology because we want to focus on Rework From Defects. In other words, what time are we wasting due to defects. So by classifying where the defects are from, we can determine where the rework comes from, and where we should put our focus on getting more efficient and thus FASTER, increasing velocity.
If our rework comes from testing, we may want to look at our test case design and test case coverage. We may also want to make sure that our testers are reporting defects accurately (including the right information such as the configuration) and completely.
On the other hand, we may find that requirements are a big source of defects. In this case, we want to make sure not only that we inspect requirements for completeness, but also make sure that the ‘handoff’ often done in grooming meetings is done optimally, where non-optimally could mean that people are just using different vocabulary, or even that the developers are in a different location than the product managers. It could also mean they don’t even speak the same first language (i.e. if development is done in Eastern Europe). OR, even if they speak the same first language, maybe they still can’t understand each other due to accents.
In summary, rework is bad news. Who wants to do things over? Because rework from defects is a major source of rework, we think it needs careful analysis.