Definition of Done

We’ve all been in a situation where the job is done, and then it turns out it’s not. It’s usually because the person doing the job believes they’ve done everything necessary, but perhaps isn’t aware of some missing steps, or the expectations of their manager, their team or their client weren’t made obvious at the outset. This happens a lot, and results in rework, frustration and friction within the team and with stakeholders.

The Definition of Done is a concept in agile that aims to help prevent these kinds of problems, and it is pretty simple to implement. The Definition of Done is simply an agreed “checklist” of things that must be true before any task can be described as “done”.

What on earth is it?

An important distinction must be drawn between the Definition of Done, which is global and applies to all items in the sprint or project, and Acceptance Criteria, which are specific to the individual task. The Definition of Done (DoD) is agreed once, between the team, based upon the workflow that most often applies, and then developers (scrum team members, with any job title) can then do a check that they have completed the DoD before dragging their card into the “done” column on the board.

For some of my projects, the DoD often looks like this:

  • Peer Code Review
  • Build Passes
  • Released to Test Environment
  • Design Reviewed
  • Documentation Complete

The important thing about the DoD is that it follows your workflow, is agreed by the team, and is actually followed by the team.

Sometimes it will be necessary to skip a step, for example where it isn’t relevant to a particular backlog item, but this should be the exception, and you should have a way of documenting that this was skipped.

How do I implement it?

The simplest way to implement the DoD is to write the list on a poster and hang it in the office where the team can see it. If you’re not colocated, then make it a “pinned post” on your knowledge tool, wiki or team chat.

There are some better, and more technical ways to implement it too.

Using a Pull Request Description Template

If you use Pull Requests in your workflow, you could create a PR description template with your DoD checklist included in it. Developers can annotate the list with any exceptions or notes on each item, or “check” them off, perhaps using emoji characters.

The downside of using a PR template is that this is not visible in your board, and many PRs may be required for a backlog item. It’s also likely the PR isn’t the last step in your DoD list, and this makes it tricky. If your workflow is pretty simple, and involves mainly software devs then this is fine.

Using Card Checklists

My favourite way to implement the DoD is using in-card checklists in your board tool of choice – for me, it’s Jira, and there are loads of plugins available for Jira that add checklist functionality.

Card checklists are ideal because they don’t suppose that every issue involves code, and they are visible to everyone at every stage of the process. Some of the tools that implement them allow you to have different checklists for different types of issue, on different projects and even to create ad-hoc items for specific cards.

The app I use for checklists is Checklists for Jira and it is very configurable. It takes a bit of getting used to, but is great for DoD.

How do I make sure it works?

The only way DoD will work for your team is if they understand the benefits and someone takes responsibility for implementing it. My top tips for success are

  1. Hold a brief workshop to introduce the DoD – explain why it’s useful and how it works. Use this workshop to compile the DoD that works best for your team. Keep it simple.
  2. Use one of the techniques above to implement your DoD list and make sure everyone knows how to access it, what is expected of them (do they check off everything at the very end or as it’s done?)
  3. Nominate someone to monitor the DoD for the first few weeks – ideally the Scrum Master should do this – to ensure people are using it, and remind them to do it if they forget. This will be necessary until it is just a habit.
  4. Review the success of the DoD during retro, and update it when necessary. It’s important that it remains relevant and useful. The team must retain ownership of it and view it as a useful tool, rather than a chore.

Have you implemented your own Definition of Done? What’s your experience been like?