Click here to Skip to main content
Click here to Skip to main content

Is definition of done no longer needed?

, 7 Jun 2012
Rate this:
Please Sign up or sign in to vote.
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

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 two 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 team's 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 two 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.

 

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Nathan Gloyn
Nock Consulting
United Kingdom United Kingdom
Passionate developer, designer, Certified Scrum Professional, wanna-be architect, agile evangelist, and presenter.
Follow on   Twitter

Comments and Discussions

 
-- There are no messages in this forum --
| Advertise | Privacy | Mobile
Web03 | 2.8.140814.1 | Last Updated 7 Jun 2012
Article Copyright 2012 by Nathan Gloyn
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid