When is the DoD done?

Blog!

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 that they are useless…

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

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 that they are useless…

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

DoD

 

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 ‘they’ knowing what was meant and “I” did not and “they” 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”, not about “doing things”, and I didn’t argue how the DoD should  add value, I just argued it shouldn’t be about “doing things”.

I did not argue their intent, but that did quickly became the center of the discussion. What I should have argued 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 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 a discussion will follow, but it will be fruitful and not awkward at all!

Published: 6 July 2015

Author: Ben Visser

Ben Visser (*1960 - +2018) 

Ben was a highly experienced test manager and test consultant. In a career of over 15 years as a tester, he fulfilled a wide range of test functions, from programmer of automated scripts, to test manager of a large international program. We thank him for his work with Sogeti and his contribution to TMap.