Nothing is more misunderstood than the term “Level of Done” in Scrum. On the first glance  Mitch [1] did a great job. And when I read this ideas a year ago I was flabbergasted. Wow – why did I had never worked with my teams on this. I must have been an idiot and I really wanted to implement these ideas in my consulting praxis. But I never did. I felt bad about this.

All people in the Scrum community around me, started to talk about the importance of the “Level of Done”, and how difficult it is to negotiate this with the Product Owner. I was again worrying. Do I do something wrong? Is it really possible not to work with your team on this? But something in me was blocked. On a sunny day in Vienna, sitting in my favorite breakfast location, it made suddenly “click!”

What people like Mitch [1], Dhaval [2] and Myank [3] sell as “Definition of Done” is not the “Definition of Done”. They found super cool ways to help people to determine on what maturity level either their developers can develop and/or at what maturity level the organization has established the code production.

To say it in more simple words: They found very nice ways to help development organizations to justify that they are not able to create potential shippable product increments at the end of a sprint. Sophisticated lists or even phrase like “Each team should collaborate and come up with the definition that suits its unique environment.” [3] are leading into the wrong direction. They make on one side transparent that this organization is not able to deliver potential product increments, but on the other side they do not help to change this.

Imagine a car manufacturer would tell his customers that the “Level of Done” he can produce is testable, without checks. The world of production does not work this way. They produce results.

“Level of Done” was never meant to be “Level of Professionalism”. Unfortunately it was understood this way. “Level of Done” was meant to tell to everybody on what level the product increment is ready. Finished on the developers machine, finished on the test machine, finished on the system integration machine, deployed to pre-production, or deployed to production. THIS WAS MEANT TO BE “LEVEL OF DONE”.

And this is the only thing you can negotiate with the PO. To talk about if we have “updated our architecture diagrams” or “operational procedure guides updated” [1]  was not meant by this term.

It is very sad, that we in our industry really need to worry if teams do their jobs professionally. That Scrum Coaches need to help professional software developers to do their job was never the intention. But unfortunately we need to do this.

—

[1] Mitch Lacey, How do we know that we are done? http://www.scrumalliance.org/articles/107-how-do-we-know-when-we-are-done

[2] Dhaval Pachal, What is the definition of Done? http://www.scrumalliance.org/articles/105

[3] Myank Gupta, http://www.scrumalliance.org/articles/106-definition-of-done-a-reference

[4] Michael Dubakov, http://stackoverflow.com/questions/170009/your-scrum-definition-of-done