Skip to main content

Creating a Definition of Done: A SoundNotes Tutorial

Dave Prior Senior Consultant/CST-CRM Specialist
Reading: Creating a Definition of Done: A SoundNotes Tutorial
Creating a Definition of Done: A SoundNotes Tutorial

Listen to the SoundNotes Podcast on the go!

Find and subscribe to SoundNotes on:

One of the most important things you can do for your team is to make sure you have a clearly defined, and well-documented, Definition of Done.

If you’ve ever seen footage of the flight control center when NASA launches a rocket you’ve seen a great example of a Definition of Done. Imagine what it would be like if NASA didn’t have all those stations that had to report in with “Go for launch” or “No Go for launch”. Imagine how that would work if we assumed we all had the same understanding of what “Ready for Launch” actually meant?

In this episode of SoundNotes, Dave Prior is giving a tutorial on how to create a Definition of Done for your team. If you’re following Scrum as it’s defined, then “done” and potentially shippable are intended to be the same thing. Unfortunately, for many organizations, this isn’t something that holds true. For example, your team may require additional integration testing that is done by a separate team and happens outside the Sprint. Yes, it’s dysfunctional from a Scrum perspective. Yes, you should try to fix it, but sometimes you’ve got what you’ve got and you’re too fully consumed with other battles.

Over the course of the podcast, Dave talks about having clarity on three different levels of done. Here’s what the three levels look like:

  1. Work that is “done” and can be presented to the Product Owner for Acceptance – this is an agreement between the PO and the Dev Team.


  • Code Complete
  • Test Cases are automated and executed
  • No defects
  • Acceptance Criteria Met
  • Pass Unit Testing
  • Pass Code Review
  • Documentation Complete as defined in Acceptance Criteria
  • Team knows how they will present feature during Sprint Review


2. Work that is “done” and can be presented to Stakeholders in the Sprint Review


  • Work has been presented to Product Owner
  • Product Owner Accepts as Potentially Shippable
  • Passes Previous Acceptance Tests
  • Demo Ready for Sprint Review
  • No Compile Warnings
  • Bugs Committed in Sprint Resolved
  • Deployment Docs Updated
  • Release Notes Updated

3. Work that is “done” and can be actually shipped to customers. 


  • Published to Stage Server
  • Passes Deployment Testing
  • Deployment Docs Delivered
  • Release Notes Delivered
  • Infrastructure Change Notes Delivered
  • Passes Performance Testing
  • Passes Security Audio

If you don’t have a clearly defined, well-documented Definition of Done that you’re updating every Sprint, you’re putting your team and your organization in danger. If you don’t already have a Definition of Done, you need one…and you need it now! In this episode of SoundNotes, Dave walks you through the creation of a Definition of Done.

Contacting Dave Prior

If you’d like to contact Dave you can reach him at:

If you have a question you’d like to submit for an upcoming podcast, please send them to

And if you’re interested in taking one of our upcoming Certified ScrumMaster or Certified Scrum Product Owner classes, you can find all the details at

Next I Just Came from the Future:
Effective Product Managers are Time Travelers

Leave a comment

Your email address will not be published. Required fields are marked *