Luis Goncalves
Last updated on | Scrum General Knowledge

Check Out This Great Definition of Done Checklist

by Luís Gonçalves
Definition of Done Checklist


When I join an Agile Team, one of the most common exercises that I help the team with is the Definition of Done Checklist. Wikipedia defines Definition of Done (DoD) as follows:

“Definition of Done is the exit criteria to determine whether a product backlog item is complete. In many cases, the DoD requires that all regression tests should be successful. The definition of “done” may vary from one Scrum team to another, but must be consistent with one team.”

The original page can be reached here.

I like to help the team to come up with their Definition of Done (DoD), but in the end, I like to challenge their DoD, making them think a bit 😉

Some time ago I wrote a blog post about what means to have a Green Build. This blog post can be found here. For me is clear that a story is only Done when all the topics of the DoD list are met, and the build is Green. Below you have a picture describing what I mean. And of course, the team is always trying to move items from the outside Box into the Green Build Policy box.


Below I am listing 15 items that you might or might not want to include on your DoD. Some of these items are more challenging than others, but this is just a basic list of ideas that can help you to define your own DoD, a general guideline; feel free to pick and choose those that best apply to your situation.

  • X% of code coverage from Unit Test
  • Automated tests for the User Story are created and pass
  • Acceptance criteria is met
  • All regression testing of the product is moving
  • System-level Non-Functional requirements ( e.g. System-level performance) tested and passed
  • Software is running in the server to be defined by the team (optimally in pre-production)
  • Code review by peer
  • Technical documentation updated
  • User documentation updated
  • User Documentation is localised
  • Localisation for the story is done
  • Localisation testing is done
  • Marketing input is done
  • Legal documents are done
  • Beta Testing is done

If you want to know how to mature your Definition Of Done, check this blog posts: “Definition of Done In Agile And What Can You Do To Mature It?

Rate this post:
Luís Gonçalves

About Luís Gonçalves

Luis is not simply a consultant, he helps people and businesses grow. He expects to deliver 10 times more value than what you’d actually pay for. As an Agile retrospective expert, customer happiness and client success are his biggest drivers!


Share your point of view

  1. A “funny” observation I have done is that general “Done” criteria and the specific “Accept Criteria” is not given very much interest when you work with a Story… Often these parts need to be requested from a test-role or ScrumMaster – or even from a department manager, before it is given sufficient focus already from start!
    Sometimes I have used the Poker Estimation and keep asking questions about how we will be able to decide when the Story is Done – but it is not a thing that comes natural to most people…
    …the list of “tricks” to ensure “Done” criteria – both general and specific ones – becomes natual for most team members to focus on – that could be an interesting add on to this list! 🙂

  2. Good examples Louis. For a team to get started with a D.o.D, initial resistance can be often be overcome by starting a D.o.D. of a list of stuff the team already does currently. This list can then be expanded with a wishlist of the stuff the team would like to do and then, in true agile fashion, incrementally move stuff from the wishlist to the D.o.D. over iterations. Start small!

  3. Hi Luis! Nice examples. Mine look very similar. I worked once at a company, where we had a strong focus on clean code. In order to keep our inner quality of the software high we also added items like the following to our DoD:

    * No major (or higher severity) issues detected by sonarqube
    * No checkstyle / findbugs violations detected

  4. Hi! Great list, indeed.

    Allow me to digress about something that I usually find to be a source of friction. Maybe you can help me make sense of it.

    Thing is, I find it very hard to include these 3 topics together:
    #1 All regression testing of the product is passing
    #2 System-level Non-Functional requirements ( e.g. System-level performance) tested and passed
    #3 Software is running in the The server to be defined by the team (optimally in pre-production)

    If we include the first two, but have it running on a QA environment on a (rebased!) feature/story branch, we can check stories/features in isolation, and burn them down individually.

    But when we test in a staging environment we typically find integration problems and people start questioning that the done stories weren’t actually done.

    So the team feels like we need to include #3 in the DoD and, as a consequence, the process starts drifting to a “massive QA at the end” of the sprint … and the feeling that nothing is really done until everything is done and tested together.

    In a couple of sprints with these 3 checks in DoD and QA running on staging environment, burndown charts start looking like a cliff in the very last couple of days. Now developers are hanging on to a bunch of pending stories, unable to get closure and move their focus to the next story during the sprint.

    Ultimately, burndown is not reflecting reality, and the lack of focus/closure has a negative impact on actual velocity.

    What are your thoughts on this?

  5. Looking at the following given definition of DoD from wikipedia “The exit-criteria to determine whether a product backlog item is complete. In many cases the DoD requires that all regression tests should be successful…”, I find something quite important is missing.
    “All regression tests should be successful” is vague and differs from team to team. To be very precise and it’s the way we should go about it, we need to base success on the success criteria attached to the US.
    Otherwise, success to one, means another thing to someone else and here is where the dilemma starts.
    Without these precise criteria at hand, developers will assume their perspective on success and the customer will also do the same.
    What do we have at the end? A functionality that is nether here or there, the developer thought one thing and the customer another. From the developer’s perspective, the US wasn’t detailed enough and from the customer’s perspective development didn’t understand business processes or needs.
    This is something I came across many organisations and it brings nothing but chaos to both groups.

    1. Thanks for your comment.

      Everything what you said is correct but thats why that DoD and everything that happens within the team should be discussed and aligned within the team.

      You will never have a global and standard DoD or Acceptance or whatever 🙂 Its based on the local context.


  6. Hello Luis,

    Good and Excellent information which you have provided which need to take care while deciding on the DoD. Thank you very much your detailed explanation and sharing the knowledge.

    Thanks and Regards