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 ;-).

Wrong Definition of DoneThe 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 Correct Definition of Donebuild 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!

Sogeti Labs

About

SogetiLabs gathers distinguished technology leaders from around the Sogeti world. It is an initiative explaining not how IT works, but what IT means for business.

Related Posts

Your email address will not be published. Required fields are marked *

7 + 1 =


  1. Julya June 25, 2015 Reply

    Hi Ben,

    Awesome insight! The DoD SHOULD be questioned regularly and updated as soon as we find that they are just a bunch of words.
    A good DoD that instills value and quality in the product is usually formed by the product actually going into production now and then. Often organisation wait until they “feel” that the product will be valuable to THEM. I have found that a product will quickly create value to the users and it comes with an added benefit when a product goes into production sooner than later. We may test until our product is black and blue, but the real test of quality comes when the product is actually used. The findings in use should also be corrected by the development team and thus they will see the quality they deliver in reality. If they are honest to themselves they use this revelation to changes their perception of Done and with that the DoD