How about a Drooming Session to groom the defects?

Generally I have found defects to be small in what is going wrong, however the cause is unkown and will not be known unttil a developer dives into the code. We don't really groom the defect, apart from a conversation with the product owner and QA if it isn't fully understand how the functionality should work.

If it is a new application for many and they don't understand the intent of the functionality or system, then a grooming session could be very beneficial, so that everyone has a shared understanding of how things should work.

Hope this helps.

In Scrum a Sprint Retrospective would be expected to uncover these issues. The output of the Retrospective should be a suitably adapted team process.

A case can be made for performing defect analysis as and when defects arise, and for adapting the process at the earliest opportunity thereafter. This will theoretically limit waste as far as possible. In Scrum the Retrospective should be seen as a formal opportunity to take remedial action, though it does not prohibit earlier and more timely interventions.

What I hear more ofthen is a zero defect policy. This means defects are fixed instant or will be accepted. This way there won't be al growing list of defects that need to be discussed or something like that.

Is their anyone with more experience working this way?

Posted By Pieter Versteijnen on 17 Oct 2014 05:06 AM
What I hear more ofthen is a zero defect policy. This means defects are fixed instant or will be accepted. This way there won't be al growing list of defects that need to be discussed or something like that.

Is their anyone with more experience working this way?

I have worked this way at my previous company - we had a zero defect policy when promoting code into the integrated testing environment. It worked really well, was totally achievable and eliminated the need for 'stabilization' (which is just time to go back and make things ACTUALLY DONE, when they should have been DONE in the first place. (check out the definition of done in the scrum guide if you want to learn more).

It leads me to think that there is a deeper, root cause for the defects that you have, that has not been uncovered yet. Maybe try the '5 Whys' game, where you continuously ask why, until you find the actual cause of having so many defects in your product/project.

Does your team have a definition of done? sounds like it might need to be revisited, to have product increments actually DONE, rather than ALMOST DONE - leaving lots of defects behind on the way.
The teams velocity may initially slow as they learn their true capacity when delivering stories to DONE, rather than 'almost done'.

Also, do you have QA sitting with the developers on the project? Fully testing user stories before marking them as done?