Thursday, 17 May 2012

Is definition of done no longer needed?

A while ago now there was a discussion about “definition of done” (DoD) with critics and supporters alike commenting on how they saw DoD and need or lack of.

The critics seemed to fall into 2 categories: those that believe work isn’t done until its actually deployed to production and those that did not see a need for DoD at all, where as the supporters generally reiterated the need for DoD and tried to explain its worth (which on twitter in 140 characters can be difficult), the most memorable tweet from these exchanges came from Hadi Hariri suggesting that DoD was akin to “agile mental masturbation”.

So are the critics right? is definition done not needed?

A definition of done

Before we go any further let me offer a definition for DoD:

“A definition of done is a checklist of “things” that need to have been completed before a item is considered finished”

Each teams DoD is likely to differ from each other as they should have been created by the team to meet the requirements/constraints they have in their environment allowing them to be happy a piece of work is complete.

The key thing with DoD is that everybody involved in the story/feature understands exactly what it means to be done, so no “oh its done but I just need to do <y> first” if you say you are done then you need to have met DoD.

The arguments against

Its not done until its deployed to production

This is a very powerful statement and goes even further than XP idea of Done, Done where the code is not only written but every thing has been completed that is needed to deploy the code, now you cannot say something is done until it is actually in the hands of the users.

I can see where this sentiment comes from but would humbly suggest that it is dependent on the environment you work in.  If you have a web based application the complexity and overhead deploying the latest version should be low but not everybody is developing web applications.  In one of my presentations on kanban I was asked about this concept, the dev in question created software that still had to be distributed by CD so he wanted to know was his work only done once the CD’s had shipped?

There isn’t a need for a definition of done

This statement came from people who I know work in highly agile environments that are focused on delivering value to the users, one person said to me “I’ve never seen a definition of done here everybody knows when the work is done”. 

For an agilista this sounds like nirvana, a team that lives agile to such a degree that they know when the work is done, no need for any checklists or wondering if Sue/Fred/thingy has remembered to do something.

I think this situation is great, but, what happens if change is introduced into the well known process? what happens when a new dev joins the team?

The argument for

For me DoD has 2 main benefits:

  1. Transparency
  2. Communication

If you have a DoD in place it is completely transparent about what needs to be done for any story/feature before you can say “I’m done”, this is understood by developers, project managers and other stakeholders, it demonstrates the actual amount of work that is required to complete a piece of work and that it is not just writing the code.

The DoD should be on display in a prominent position, it is there for everybody to see. If somebody new joins the team/business everybody can see what’s needed to mark a story/feature as done it is very visible for the team and it serves as a reminder of what is expected of them or to a business person what is involved in getting the work done.

The Verdict

To my mind the need for a DoD is essential, it doesn’t matter if you are doing agile or waterfall, it is having the ability not only as a development team but as a business to understand everything that is required to complete a story/feature.

The argument that its not done unless its in production is a very powerful one and as I mentioned earlier if you are in an environment where you are able to do that I would suggest that adding “deployed to production” as an item to your DoD. However, if the environment you work in doesn’t allow this then I would suggest you should be including a deployment to staging/testing/UAT to ensure that you can deploy the software and does what you expect.  For me this argument doesn’t replace the need for a DoD but I strongly believe you should be thinking about the idea behind it to understand the need to deliver value to the user for the business.

I don’t believe the argument that there isn’t a need for a DoD holds any water, the only downside to having a DoD I can see is if it becomes so prescriptive that development is becomes just one of a myriad number of tasks on the list, if that is the case then perhaps the team has missed the point and needs to re-evaluate what their DoD is for.

So is DoD needed any more? Yes, and IMHO its a key part of the development process that all teams, agile or otherwise, should be looking to use if they don’t already.


  1. Those who don't see a need for DoD (from the examples above) seem to live in a high visibility, high trust environment.

    It's not that they don't have a DoD, it's just so well understood and ingrained that it has become implicit.

    The other scenario that I can imagine are those who do not favour quality/craftsmanship as much, in which case a DoD is a barrier to them getting code out.

    Now, getting code out quickly is the ultimate goal, so that we can test our ideas. I do not see this argument as a black/white scenario: there needs to be a balance between doing things right, and doing the right thing.

    Unfortunately most teams don't live in the world I initially mentioned, and haven't built up the experience needed to get the balance right - they will often restrict themselves on actually delivering at the outset by setting the DoD bar too high, or they will produce so much crap that they get swamped in technical debt.

    This is why I see a DoD as invaluable, but we must remember that it is only one system amongst many, and we need to cultivate all the systems in tandem in order to progressively improve.

    A lot of teams trip up because they only focus on one thing, like DoD, to the detriment of other systems. Treating all system equal show hopefully let you reach those nirvana-like points where you have built an environment based on humanistic values, and that's when you can start to drop things like specific DoD's

    1. You have valid points but if you are working in a non-agile environment with no opportunity to implement any agile practices DoD still has value and can be used where other practices simply won't be entertained by the Co.

      It is the fact that DoD can be useful both in an agile & non-agile environment that IMHO makes it something that all teams should use.