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.”

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.

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, you can expand your Definition of Done to reflect a higher standard of quality.