How To Create Your Team’s Definition Of Done

A scrum team’s definition of done is an important tool that helps the team add new functionality while keeping the product in a releasable state. Here is one way of facilitating the creation and evolution of your scrum team’s definition of done.

Identify The Work Needed To Release Something

Have the development team identify all of the work items (often called tasks) needed to release a high quality product backlog item (often called a user story) to production. Each piece of work goes on a sticky note. Be as specific as possible. If a team member says “testing” get specific about what that entails and write specific sticky notes:

  • Each acceptance criteria has an automated regression test
  • Unit test coverage is greater than 80%
  • Manual exploratory testing has been done
  • All the tests are passing

Put all the sticky notes on the wall in an unsorted clump. Keep asking if there is additional work needed to release a product backlog item until the team feels they have captured it all.

Definition Of Done For A Product Backlog Item

Put a label that says “Definition Of Done For A Product Backlog Item” over an empty section of wall. One by one, team members pick a sticky note that they think would be reasonable to add to the team’s definition of done and they propose that this be added. Adding this means the development team can, and will, do that work for each product backlog item before declaring that item done. If the entire team agrees, then the sticky note gets added. If not, it’s returned to the group of unsorted sticky notes.

Eventually the nominations will stop; there are no additional sticky notes that the team is willing to consider for their definition of done. Have the team look at the list and reaffirm that they are willing and able to do each of these pieces of work for each product backlog item before they consider it done. Adjust as needed until there is consensus that this is their definition of done for a product backlog item.

Definition Of Done For A Product Increment

With the remaining unsorted sticky notes repeat the process from above, but this time have the team members select the work that they can do by the end of a sprint in order for the product increment (the collection of completed product backlog items) to be truly releasable. This becomes the team’s definition of done for a product increment.

Warning! Any items that can only be done at the sprint (product increment) level represent technical debt and increase the risk that the increment might not be releasable at the end of the sprint.

Definition Of Done For A Release

One the premises of scrum is that the team produces a releasable product increment at the end of each sprint. So there shouldn’t be any additional work left. In reality, your team may not be there yet. Perhaps there are still some sticky notes in the unsorted category. These remaining items are significant technical debt and greatly increase the risks related to shipping the product. For now, consider these your definition of done for a release.

Evolving The Definition Of Done

The ideal is having one definition of done, which applies at the product backlog item (A.K.A story) level. Each time a product backlog item is done the business has a releasable product increment and we are leaving no undone work behind. This allows the business to capture the value from the work the team has done as quickly as possible.

In pursuit of this goal, the team and perhaps the entire organization will want to do work in order to promote things from the release definition of done to the product increment definition of done and from the product increment definition of done to the product backlog item definition of done.

Another reason that the definition of done evolves over time is that the team will discover weaknesses or gaps in their definition of done over the course of their work. For example:

  • In product backlog refinement, the team might notice that a particular acceptance criteria is almost universal and so they add it to the definition of done.
  • In sprint planning, the team might notice some vital work that isn’t currently captured in the definition of done.
  • In the daily scrum, the team may surface impediments that could be avoided by a stronger definition of done.
  • In sprint review, the team might discover missed stakeholder expectations and decide to add stakeholder signoff or user acceptance testing (UAT) to the definition of done.
  • In retrospective, the team might identify some ways a stronger definition of done might have prevented the introduction of bugs during the sprint.

Do It Early And Often!

If you are working with a new team, facilitating the creation of their definition of done should be one of the first orders of business. Don’t worry about getting it perfect or ideal; it’s more important that it be realistic. Then you begin the journey of evolving and improving the definition of done over time.

This entry was posted in agile. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.


  1. Joe C.
    Posted May 7, 2018 at 10:38 am | Permalink

    In the case that you have two distributed development teams working on the same backlog, should both teams have the same definition of done, or can they be similar but keep each team informed of their definition?

  2. Posted May 22, 2018 at 2:22 pm | Permalink


    When multiple teams are working in the same codebase, I recommend that they have a shared definition of done. That way, no matter which team completes a give product backlog item, the business can count on level of quality and readiness for release.



Post a Comment

Your email is never published nor shared. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>