When is the DoD “Done”?

What do you think of “Definition of Done” items like “All source code has been reviewed” or “All user stories have been tested”? I think they are poor, to the point of being useless …

Not everybody agrees with me on that. Actually, these are real life examples, so there are entire Agile teams that disagree with me ;-).

The first time I questioned a DoD, phrased like this, I argued that ‘just doing something’ does not guarantee quality. What if the reviewer’s remarks are not followed up? What if the tests fail?

I very quickly found myself in a rather awkward discussion around ‘others’ knowing what was meant and ‘I’ did not and ‘others’ knowing and trusting each other and, again, ‘I’ did not. Basically, the discussion became very personal with an implicit undertone of “you don’t understand Agile.” It ended very unsatisfactorily and in a bad, almost hostile mood.

So, where did I go wrong? I reluctantly admitted to myself, they had a point … I did not argue my case from a true Agile mindset. Agile is all about “adding value,” and not about “doing things”; so, I didn’t argue how the DoD should  add value, I just argued that it shouldn’t be about “doing things.”

I did not question their intent, but that did quickly become the center of the discussion. What I should have argued about was the added value of phrasing it like this, because I fully agreed on the intent, which in this case was to “deliver high quality source code that complies with coding and design standards” and “user stories meeting their confirmations”.

Is this then the way a DoD should be phrased? Yes! A DoD should be ‘product focused’ instead of ‘process focused,’ it should reflect the state of the product.

And to make it even better, make sure that the process of assessing the product’s state is automated, as part of your continuous build and delivery cycle:

• Current development environments support automated verification of coding and design standards. Use that! Have it reflected in your DoD: “the coding standards and style guide checker returns no warnings or errors.”
• Automated tests are part of Continuous Delivery. Use that! Have it reflected in your DoD: “All confirmations are part of the automated test set” and “All tests in the automated test set pass.”

So, the next time I encounter a poor DoD, I won’t argue that “quality does follow from just doing things,” I’ll argue that a DoD must add value and therefore, be product focused, preferably automatically verifiable; and I’m quite confident that a discussion will follow, but it will be fruitful and not awkward at all!

This article was previously published in the SogetiLabs Blog.

Ben Visser is a highly experienced test manager and test consultant. In a career of over 15 years as a tester, he has fulfilled a wide range of test functions, from programmer of automated scripts, to test manager of a large international program. He has worked in traditional waterfall developments as a change manager responsible for test and acceptance environments, as well as model-based testinDo. More on Ben.