Can anyone recommend a format for facilitating a definition of done meeting ie, a meeting to define the teams definition of done.

I was thinking of first looking at artefacts and then associated a checklist with each eg epic, story, release and then definition of done for each of those.

Any ideas would be greatly appreciated.

  • What do you mean by "definition of done meeting"? A meeting to decide what the DoD for your Team should be? A meeting to go over all "done" items in the Sprint to determine if they're "done-done"?
    – Sarov
    Nov 20 '17 at 14:55
  • "done-done" is a horrible phrase the demeans the purpose of the Definition of "Done" Nov 23 '17 at 14:12

One of the approaches I've used in the past that works pretty well, especially with multiple teams:

Set up a flip chart for each team and put a dotted line about 1/3 of the way up (so the top section is 2/3 of the chart). Explain definition of done (I also provide examples like "X% test coverage with all tests passing" and "merged to trunk") and ask them to brainstorm what they want on their DoD with sticky notes. The top section is for the things that they can do for each backlog item every sprint. The items in this section will be the team's Definition of Done.

The bottom section is for items that they would like to do but can't commit to each sprint. I often see things like full regression test runs and deploy to production down there. This is important because it gets these limitations out in the open. It creates opportunities for the team and organization to improve in the future and calls out the technical debt and risk that is building with each backlog item that doesn't do those things.

Finally, if you have multiple teams, have them walk around and look at the other teams' DoDs to see if they came up with something that they like and want to use.

You can do the same thing for Definition of Ready if you're using one. (In my experience, you don't need to make two sections for the definition of ready chart)

And of course, this is a living artifact, so this is just to get you started.

  • So once you've made the chart, what's the actual DoD? Just the stuff above the line? Or does it vary depending on whether or not some of the stuff below can be done for a given piece of work?
    – Sarov
    Nov 20 '17 at 15:32
  • Great question, I'll amend my answer to be clearer about that, but yes, the stuff above the line is your DoD. The below the line is stuff you want to figure out how to make part of your DoD later. I've seen some teams compile the stuff below the line into a "Release DoD" if they're worried that some of the items might get forgotten, but I don't push teams to do that unless they really want to.
    – Daniel
    Nov 20 '17 at 15:35
  • I used this method and it worked wonderfully well even with some very closed minded team members. Much appreciated.
    – TheLearner
    Nov 22 '17 at 12:41

Build it incrementally.

Agile isn't just about completing work incrementally; your process itself should evolve as you learn more about yourselves and the business.

So, don't stress too much about the initial Definition of Done, as it should change. Just have a simple meeting to get something out and ready. If anything, I would err on the side of simplicity, as, psychologically speaking, it is easier to add than to remove. Just keep it to the bare essentials at first (e.g. needs to run properly in Production environment, needs to be code reviewed, etc.)

Expand from there as needed, once needed.

  • 1
    And as you do so, the retrospective is the natural place to discuss changes to your DoD.
    – yitznewton
    Nov 20 '17 at 17:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.