How important is the 'Defect Leakage' metric in SCRUM? [closed]

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 4 years ago.

Improve this question

I was reading about the necessary metrics for SCRUM and I couldn't find 'Defect Leakage' listed in there. This is the case even with the papers published by Jeff Sutherland.

I was wondering if there is any reason behind not considering this as an important metric in Agile SCRUM. Does anyone know?

Answer 1

There are no metrics in SCRUM. This doesn't mean you can't have metrics, it just means that SCRUM doesn't mandate them nor tells you what you should do in this case, hence why you aren't finding anything of the sort.

Since we're talking about SCRUM, one usual mindset to this is to ask ourselves:

• is it useful? Does this <activity,metric,task> have a big value?
• why do i want to do this? What will i get from it?

So instead of looking for the answer, i suggest you answer yourself that.

(PS: my boss asked me to is not the greatest motivational answer)

Answer 2

Scrum is a minimal process improvement framework. It very deliberately doesn't talk about any metrics beyond meeting the sprint goal.

If your team find defect leakage a useful metric in helping them improve then they are, of course, allowed to use it. If the management outside of the Scrum team find defect leakage a useful metric - then they're perfectly free to use it too.

Scrum doesn't define the metrics you should use. It allows you to use any that you find effective.

Answer 3

If you take a look at the Scrum Guide you can see that Remaining Work is only metric mandated as part of the Scrum Framework. As long as you can monitor Remaining Work you are at least looking at that one "thermostat" for your project.

Does that mean that you should not look at anything else? Heck no... as long as you continuously monitor your metric usage and watch for negative impacts on the team and organisation you can monitor whatever you like. Some teams require to do time-sheets for financing while other like to monitor mean-time-to-resolution or build quality. Although after looking up "defect leakage" I would question its usefulness.

p.s. Scrum is a noun and not an anachronism and so does not need capitalised

Answer 4

Scrum should not be set-up as an excuse for bad code or for defect leakage. If there is leakage, that means there will be items being added back into your backlog and unhappy clients. Most teams that I talk to using scrum also try to use techniques from xtreme programming, like test-driven development, junit tests, automated regression test scripts. No matter the tools, you should have QA resrouces booked 100% on the team, who are ultimately accountable for their processes around issue management and the quality of the deliverable that is deployed at the end of each sprint.

Another thought: if defect leakage is a metric expected by the enterprise, you could consider treating it as a criteria on a user story for sprint 0. But, if it's not important to the project or enterprise in general, you probably won't get it from the team during execution, or the team might implement it when problems arise in an adhoc, tactical manner.