The basic idea to get your initial Definition of Done is to get everyone's perspective on what it means to do complete, quality work from their perspective. Perhaps the analyst has one view, QA another, the architect a third, and the customer another view.

This leads to the following facilitated event:

• Review any organizational standards for the Definition of Done and ensure there is understanding of the implications of that standard on the work the Team does.
  • Note: It's OK to say a Definition of Done item is “Not Applicable” if it truly does not make sense in apply to the work you are doing. Be transparent about these items so that there are no false expectations.
• Within the Team have the whole Team brain-write down candidate items for Definition of Done, with one idea per sticky-note. Have people consider their own view of what it means to be done first (e.g. the QA person on a Team would have different perspective than the Developer, or the Product Owner). Then have people consider a wider prespective, including other stakeholders to the work. Again, this is aimed at “potentially shippable” (include work required before released into production) and establishing your quality standard. Note: These are not features of the product but rather aimed at “intrinsic” quality:
  • It could be a part of a process. For example, code review, security review, etc
  • It could be a deliverable example: For example, an automated test, end-user documentation, etc.
• Have each person read out each other their items, stick them up on a (virtual) whiteboard.
• Affinity map like items
• For each item review and discard those that don’t have value. Ask questions like
  • “Does this make sense to do?”
  • “Do we all agree this is part of our DoD?”

Once complete, this is your Definition of Done. Document it and make sure its part of every planning session you have.

Once we’ve defined “done”, how does it actually get done. Lets look at the Team level (similar thinking can be applied at the Train level). At the heart of this work is a Team who is going to do the work. If a Team breaks down work to tasks some of these tasks might come from the Definition of Done. For example, perhaps an automated test is part of the Definition of Done for every Story. Assuming we are not doing Test Driven Development, then there might be a task that says “develop automated test”. In this way as you are working the board you are insuring quality every step of the way.

What this effectively means is that you treat your Definition of Done as a checklist. For each item of work that comes in you are “does this DoD item make sense for this story?” If yes, then using this example, you add a task to the board. If not, continue. And so on.

You might be thinking “Wow, checklists. That sounds pretty process heavy.” I've found that checklists are useful to make sure you don't forget the simple stuff, while concentrating on all the complexity of the problem we are working. For more on this thinking see The Checklist Manifesto - How to Get Things Right by Atul Gawande

The Definition of Done does not remain static. The Team is always looking at ways to improve how they deliver quality and, as they get better, they will adjust the Definition of Done. So it is a living definition that you will revisit on a regular basis.

Sometimes you will encounter the situation where you would like to improve the Definition of Done, but as yet you cannot as you don't have the capability. For example, perhaps your Team has never done automated testing before and now would like to do it. In this case your could create a Feature or Story that defined the work to figure our how to do work (automated testing in this case), and the acceptance criteria might include something like “Must become part of our Definition of Done”.

• What Does It Mean To Be Done?
• Agile Alliance Definition of Done
• Scrum.org Blog Post Walking Through a Definition of Done
• The Checklist Manifesto - How to Get Things Right by Atul Gawande