The Definition of Done (DOD) is a key artefact mentioned in the Scrum guide 2016:

When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done”means.

It is the cornerstone for understanding whether a User Story or piece of work is completed. I follow a formula which starts with a very basic DOD and then gets gradually more complex. This is to help the team define it’s processes, inspect and adapt and gain pride in the product they are creating.

A simple DOD example would be:

  1. Feature complete
  2. Code/Activity  complete
  3. No known defects
  4. Approved by the Product Owner
  5. Production ready

This is just a skeleton but is typically where I would start with a team. This is an actual DOD that I used with a start-up in the legal sector. A more advanced version used with a more mature team is:

  1. Design approved by Architect
  2. Development /coding complete
  3. Solution builds successfully – (Passes code analysis)
  4. Everything checked in to source control – including code and scripts etc
  5. TFS/Board up to date
  6. Code coverage with Unit Tests – 100% coverage of logical code
  7. Code Review – Code and tests reviewed – (peer to peer review)
  8. Deploy to Test Environment
  9. DB review
  10. All COA’s are met
  11. All tests pass
  12. No known critical defects
  13. Demo to Scrum Master
  14. Complete documentation including release notes
  15. Sign off from relevant parties
  16. Product Owner is happy
 You can also extend this powerful document to cover other activities. I worked for a company in the automotive sector and helped create a Definition of Done for the Scrum Masters:
  1. Review Impediments and seek resolution
  2. Impediments external to team escalated (Update Development Team Impediments Board)
  3. Provide sprint burn down updates to the team (Ensure emailed and all members are aware)
  4. Print daily burn down and advertise on the Scrum board
  5. Ensure/Facilitate accuracy of the Scrum board
  6. Tasks updated
  7. Support Statistics updated
  8. High risk/impact impediments highlights
  9. Sprint work reviewed
  10. TFS accurate (Tasks completed are code reviewed, test cases raised for user stories, rework completed and tested)
  11. Catch up with development team members at local machine to run through project work in progress
  12. Facilitate product backlog grooming / prioritisation
  13. Carry out completed test cases which are “ready to test”
  14. Put time towards study/research/future strategy with the aim of improving development standards

You can accomplish many things by applying the logic of this document to many scenarios. I have worked with a complimentary document called the Definition of Ready to top and tail the development process by acting as a quality gate for work entering the SDLC

I’d love to hear from you if you have other interesting and effective ways of using this document.