Agile FAQs
  About   Slides   Home  

Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
RSS Feed
Recent Thoughts
Recent Comments

Done with Definition of Done or Definition of Done Considered Harmful

TL;DR: Definition of Done (DoD) is a checklist-driven project management practice which drives compliance and contract negotiation rather than collaboration and ownership. Its very easy for teams to go down rat-holes and start to gold-plate crap in the name of DoD. It encourages a downstream, service’s thinking mindset rather than a product engineering mindset (very output centric, rather than outcome/impact focused.) Also smells of lack of maturity and trust on the team. Bottom line: Its a wrong tool in the wrong people’s hand.

The Scrum Guide™ describes DoD as a tool for bringing transparency to the work a Scrum Team is performing. It is related more to the quality of a product, rather than its functionality. The DoD is usually a clear and concise list of requirements that a software Increment must adhere to for the team to call it complete.

They recommend that having a clear DoD helps Scrum Teams to:

  • Work together more collaboratively, increases transparency, and ultimately results in the development of consistently higher quality software.
    • Clarifies the responsibilities of story authors and implementors.
  • Enables the Development Team to know how much work to select for a given Sprint.
    • Encourages people to be clear about the scope of work.
  • Enable transparency within the Scrum Team and helps to baseline progress on work items
    • Helps visualize done on posters and/or electronic tools.
    • Aids in tracking how many stories are done or unfinished.
  • Expose work items that need attention
  • Determine when an Increment is ready for release

Also according to them, DoD is not changed during a Sprint, but should change periodically between Sprints to reflect improvements the Development Team has made in its processes and capabilities to deliver software.

According to the LeSS  website– DoD is an agreed list of criteria that the software will meet for each Product Backlog Item. Achieving this level of completeness requires the Team to perform a list of tasks. When all tasks are completed, the item is done. Don’t confuse DoD with acceptance criteria, which are specific conditions an individual item has to fulfil to be accepted. DoD applies uniformly to all Product Backlog items.


If you search online, you’ll find sample DoD for user stories more or less like this:

  1. Short Spec created
  2. Implemented/Unit Tests created
  3. Acceptance Tests created
  4. Code completed
  5. Unit tests run
  6. Code peer-reviewed or paired
  7. Code checked in
  8. Documentation updated
  9. 100% Acceptance tests passed
  10. Product Owner demo passed
  11. Known bugs fixed

Another example:

  1. Upgrade verified while keeping all user data intact.
  2. Potentially releasable build available for download
  3. Summary of changes updated to include newly implemented features
  4. Inactive/unimplemented features hidden or greyed out (not executable)
  5. Unit tests written and green
  6. Source code committed on server
  7. Jenkins built version and all tests green
  8. Code review completed (or pair-programmed)
  9. How to Demo verified before presentation to Product Owner
  10. Ok from Product Owner

Do you see the problem with DoD? If not, read on:


  • Checklist Driven: It feels like a hangover from checklist driven project management practices. It treats team members as dumb, checklist bots. Rather than treating them as smart individuals, who can work collaboratively to achieve a common goal.
  • Compliance OVER Ownership: It drives compliance rather than ownership and entrepreneurship (making smart, informed, contextual decisions.)
  • Wrong Focus: If you keep it simple, it sounds too basic or even lame to be written down. If you really focus on it, it feels very heavy handed and soaked in progress-talk. It seems like the problem DoD is trying to solve is lack of maturity and/or trust within a team. And if that’s your problem, then DoD is the wrong focus. For example, certain teams are not able to take end-to-end ownership of a feature. So instead of putting check-points (in the name of DoD) at each team’s level and being happy about some work being accomplished by each team, we should break down the barriers and enable the team to take end-to-end responsibility.
  • Contract Negotiation OVER Collaboration: We believe in collaboration over contract negotiation. However DoD feels more like a contract. Teams waste a lot of time arguing on what is a good DoD. You’ll often find teams gold plating crap and then debating with the PO about why the story should be accepted. (Thanks to Alistar Cockburn for highlighting this point.)
  • Output Centric: DoD is very output centric thought process, instead of focusing on the end-to-end value delivery (outcome/impact of what the team is working on.) It creates an illusion of “good progress”, while you could be driving off a cliff. It mismanages risks by delaying real validation from end users. We seem to focus more on Software creators (product owners, developers, etc.) rather than software users. Emphasis is more on improving the process (e.g. increasing story throughput) rather than improving the product. Ex: It helps with tracking done work rather than discovering and validating user’s needs. DoD is more concerned about “doing” rather than “learning”. (Thanks to Joshua Kerievsky for highlighting this point.)
  • Lacks Product Engineering Mindset: Encourages more of a downstream Service’s thinking  rather than a product engineering mindset. Unlike in the services business, in product engineering you are never done and the cycle does not stop at promoting code to high environment (staging environment). Studying whether the feature you just deployed has a real impact on the user community is more important than checking off a task from your sprint backlog.

What should we do instead?

Just get rid of DoD. Get the teams to collaborate with the Product Management team (and user community, if possible) to really understand the real needs and what is the least the team needs to do to solve the problem. I’ve coached several teams this way and we’ve really seen the team come up with creative ways to meet user’s need and take the ownership of end-to-end value delivery instead of gold-plating crap.

  • Dhaval Shah

    Hi Naresh,

    Out of curiosity, what do you mean by gold-plating crap, and are there any examples to highlight this?

    • Gold-plating crap ex:
      1. Using the latest, great javascript library to show user activity in pretty graphs. However there are only 3 users of the system. And they use the system via an API call.
      2. Building a home grown load balancer to handle 14 requests per minute load.
      3. Creating a database abstract layer, but 90% of the queries are native query which are tightly coupled with the existing database.
      4. And so on…

      • Dhaval Shah

        Thanks for the clarification – they do seem pretty gold-plated. In your opinion, how has a DoD contributed to these things occurring?

        • IME DoD encourages local optimisation, not global. That is, it can allow the team to work in isolation from the real users. The team feels they should be “Done, as in Done” before they can deploy it. Which does not encourage the “good enough for now, let’s deploy and see what happens” thinking. There is a fine line between over-engineering and just hacking away. One way to really know where to draw the line is to get constant feedback from real users and not be hung-up in these artificial (static) DoD.

          • Dhaval Shah

            Hi Naresh,

            Your choice of language is interesting – you talk about a DoD ‘encouraging’ local optimisation and ‘allowing’ a team to work in isolation, and I agree that it can. The DoD is IMO a tool, however, and if the tool is misused then yes, bad things might potentially result from the misuse.

            With the information that you’ve provided so far, my follow-up questioning would be to understand why these things occurred; building a bespoke load balancer to handle 14 requests/minute wouldn’t have happened overnight, and certainly not in the teams that I’ve worked in where a stable DoD has been established. From experience, having a DoD and employing a test-and-learn approach are not mutually exclusive.

          • Agree that DoD and Test-and-Learn approach are not mutually exclusive. But why add more process, when I can do away with it and still achieve want I want to achieve? It seems like a wrong focus. Have you tried doing away with DoD? If yes, what problems did you run into?

          • Dhaval Shah

            The point I was alluding to previously was that I don’t think having a DoD in place was the issue – rather, you’re building the wrong thing. If your DoD is leading to this then from experience there’s some dysfunctions that need to be resolved, and correlating this to having a ‘contract’ in place is asking the wrong question(s).

          • Just so you understand the context, these gold-plating stories are from various teams I visited. I was shocked to see what was going on. The team were arguing that they did what their DoD said. Certainly all of us make mistakes and in this case the PO was cooking up stuff. But the team was not questioning it, instead treating DoD as a contract that they had to meet. And that’s what the “certified” Scrum Master was forcing the team to do. In 12 years of my agile experience I had never used DoD and I was surprised teams found them useful. After removing DoD, we’ve seen significant improvement in the collaboration.

            You could argue that they were not using DoD, Scrum, etc. how they were supposed to us and they should learn that. Fair enough. My solution was to get rid of useless process and fix the problem. Your mileage may vary.

          • Dhaval Shah

            Hi Naresh,

            I understand where you’re coming from, and there’s a number of things that I’m going to respectfully challenge.

            Inferring from what you’re saying, by providing a solution for the team the team doesn’t grow and learn to question themselves; steering a team is fine, but ultimately a team needs to figure out what they’re doing is not optimal. A misuse of a tool is a misuse of a tool, and when you have a hammer, everything looks like a nail; it doesn’t mean the hammer is the right tool to use. If removing the DoD resulted in a significant improvement in collaboration, I would want to know why the team was not challenging the outcomes they were getting (as opposed to removing something that appears to have used as a mechanism to not challenge the status quo).

            I’d also be wary of using emotive language – ‘useless’ and ‘shocked’ in this context feels very provocative. Imagine if you were an individual in one of these teams who were gold-plating work and were told you were performing ‘useless’ activities – do you think that’s like to inspire a positive or a negative response? People don’t know what they don’t know – that doesn’t mean they should be berated for a gap in knowledge and/or understanding.

          • I was a consultant, not a coach. I’m sure you understand the difference between the two. My job was to challenge the team and get them to think differently. Which I’m glad they did.

            Did the team learn & grow from this exercise? Were they demoralised & negatively impacted? That’s for the team and its leadership to decide. Trying to pass judgments over a blog comment without understanding the context, seems rather hypocritical.

          • Dhaval Shah

            I absolutely agree – which is why I make an assessment on the information provided. If context was/is important, then ultimately it’s up to the author to provide it if they felt it was essential. Respectfully, further context was only provided (and then some) after the initial discussion about whether it was a DoD was the problem (or something else). That being said, especially when using a low-bandwidth medium such as the written word things like this are bound to happen, and I’m happy that more information has been revealed so that a constructive debate can occur.

            Irrespective of what role was taken with the team, I believe the use of language is hugely important – it doesn’t matter if you were acting as a consultant or a coach, people don’t know what they don’t know and the use of emotive language can unintended consequences. How do I know? Because I’ve misused language in the past on several occasions and had negative things happen as a result, and so I’ve used these experiences to steer future conversations to better outcomes.

          • Appreciate your perspective. Totally agree with the importance of using the right language with the right set of people.

            Just to clarify, this blog was not based on just one instance with one team. Its more of an anti-pattern I’ve seen with several teams over the years. What was communicated to teams, is very different from what was taken out of context and communicated in the blog and comments.

  • Chris

    It seems that none of the ‘gold-plating crap’ examples provided by Naresh Jain are problems with the DoD. Stories like those should never have made it into a sprint in the first place. If you want to do scrum, the product owner and the scrum master should make sure that the stories they pick are actually useful. Not doing this is quite the opposite of agile development. The definition of done should make sure that a story is really done when it is supposedly done. This make sure that no story is advertised as done while there are still problems with them. In that case one can really immediately ship a feature when all its stories are ‘done’. Also, if a story is not really done the problems that remain with it carry over to subsequent sprints and the velocity becomes unpredictable.

    • >> The definition of done should make sure that a story is really done when it is supposedly done. This make sure that no story is advertised as done while there are still problems with them.

      Does this not sound like a fundamental lack of trust problem? Why use DoD (contracts) to tackle this problem. Instead collaborate and work with the team, which is the spirit of Agile.

  • witko

    I read this article when you first published it and revisited it today. Great read and something which I agree with completely.

    Licensed under
Creative Commons License