Here’s a video I shot for freeCodeCamp about the Definition of Done.

The Definition of Done is a documented team agreement. It defines the conditions that must be met for a potentially shippable product to be considered “done as in done.” It’s how we know that we “did the thing right”, meaning that we built in the correct level of quality into the product. These are different from the acceptance criteria which help us know that we did the “right thing.”

Click “Continue reading” below for a transcript.

Hi, my name is Chris Gagne and I am an Agile Coach. Today I will talk about the Definition of Done.

The Definition of Done is a documented team agreement. It defines the conditions that must be met for a potentially shippable product to be considered “done as in done.” It’s how we know that we “did the thing right”, meaning that we built in the correct level of quality into the product. These are different from the acceptance criteria, which are written by the product owner and help us know that we did the “right thing.”

[Note: I should note that my statement “…the acceptance criteria, which are written by the product owner…” is technically incorrect. Anyone can write the initial draft of acceptance criteria (although it’s often the product owner, especially for user stories), and the team improves the acceptance criteria together at Backlog Refinement and Sprint Planning.]

Creating and following the definition of done diligently can easily double the speed of an Agile team. Lean practitioners will tell you that in the long run, quality is free because if you don’t build a quality product in the short run, you will pay for it in the long run due to increased technical debt, the slow pace of manual testing, and production bugs. Having lots of hidden, undone work in your product will make releasing your feature to customers difficult and risky.

Scrum doesn’t really talk about this in much detail, but many less-mature companies use two sets of Definition of Done. One is targeted at what you consider “Done” for a single product increment that you bundling into a release. The other is the definition of done for that release. Over time, you want to improve your practices, environment, and team structure so that you can potentially release any given product increment at any time.

What should you include in your Definition of Done? At a minimum, you will want your work to be:

  • Code complete
  • Unit, integration, and performance tested
  • Just enough documentation
  • No new bugs or technical debt
  • Accepted by the product owner as meeting the acceptance criteria

I suggest spending an hour as a team to review sample definitions of done and craft your own. Then review your definition of done periodically, such as at retrospectives. At the beginning, your Definition of Done may just have a few items. As your team and automation matures, expand your Definition of Done to include more scope.