In which I describe a proposed exercise for arriving at a Definition of Done.

This post

My Scrum team doesn’t yet have a written Definition of Done and we’ve gone a couple rounds of individual proposed drafts without feeling consensus, so I’m taking a shot at facilitating a little exercise to get to a written Definition of Done. I’m using this blog post to gather my thoughts in preparation. I’ll update the blog post afterwards sometime with thoughts on how this went.

What is a Definition of Done?

A Definition of Done is a set of criteria that work product typically meets in being considered “complete”.

You have a definition of done

You have a definition of done whether you’ve written it down or not. You’re presumably doing things, after all, and at some point you probably say some of them are done.

The advantage in writing it down is it becomes a tool, becomes amenable to inspection and adaption, and it becomes more apparent whether and how the unwritten definitions of done team members are carrying around in their heads overlap and differ.

Definition of Done in the Context of Scrum

Scrum is an agile process.

In Scrum, there’s a Product Backlog that’s a prioritized queue of Stories representing features your product should have.

Each Sprint, the Scrum Team pulls some Product Backlog Entries (Stories) into a Sprint Backlog. The Team tries to select an amount of scope that can be delivered within the Sprint and commits to focusing on and doing what it takes to make those Stories Done during that Sprint to the exclusion of other work and distractions.

During the Sprint, the Team works the issues, taking them to a level of completeness that is Done. The goal and commitment by the team is that by the end of the Sprint the selected scope will all be Done. The Team typically graphs this as they go showing a lovely burn down chart.

At the end of the Sprint the Team showcases the stories Done during the Sprint at a Sprint Review meeting and Product Owners accept the work product as really Done, reject Stories as not actually Done, and the whole team learns from what has been achieved in considering what next ought to be achieved.

The Definition of Done provides a template for what it means for those Stories to be Done. The Team bears that definition in mind in estimating Stories and in choosing a scope to commit to each Sprint. The Team bears that definition in mind in determining what technical tasks are involved in making a Story Done. The Team and Product Owner judge Stories against the Definition of Done as well as against functional requirements in the Sprint Review meeting.

Definition of Done as Rubber Stamp

I love this one:

So, part of the idea of Stories is that they can fit on an index card. Some processes actually use physical cards, though simulating cards in [JIRA Agile[] or so is more common.

Typically on the front of the card the Product Owner would write something like:

As an advisor I would like quick access to my advisees’ contact information so that I may more readily keep in touch with them.

Conceptually what a Definition of Done is is a rubber stamp for the back-side of the card. It’s the things that the Product Owner typically wants of every Story and so it’s more efficient for them to be implied rather than redundantly stated on every Story.

As an advisor I would like quick access to my advisees’ contact information (respecting their Preferred Name) so that I may more readily keep in touch with them. Of course, this feature should be unit tested so that it is less likely to regress. The user interface should comply with the Style Guide, should of course be built with good accessibility practices, and should be responsive across window sizes. It should work properly under our supported browser and device matrix. The code should have relevant JavaDoc so as to better document its intentions for future developers. Oh, and the code should pass through code review. Also, routine logging should be built in so that in a pinch cranking up logging facilitates troubleshooting. Oh, and the source code of this module should be in a public GitHub repo clearly licensed as Apache 2 so that there’s a cleaner path to getting future help with it and perhaps collaborating with other adopters — hard to have those serendipities when they’ve been made impossible through hiding the code! Also, I’d like this to be built using the standard View-Controller-Service-Registry-DAO-JPA layered architecture for the advantages of that architecture. The user-facing labels and messages should be externalized into a localizable, internationalizable message bundle. And I almost forgot — this should be deployed to a test tier for demoing and review and so we don’t have that “works only on my laptop” scenario.

Imagine saying that for every Story. Gross. You’re clearly not going to do that, of course. But the pithy version of the story implied at least some of that.

Prior Art

I didn’t actually find and read this article before designing the exercises I describe in this blog post. I wish I had, since it looks like Mitch Lacey & Associates came up with something very similar to what I came up with.

That exercise is better than mine in that it:

• Includes a calling-out-ideas-out-loud feature in the brainstorming step that probably yields more ideas through prompting. Probably a great idea, but I also value the uninterrupted “flow” that participants can get into without the calling-out. Also, for an initial Definition of Done, I don’t expect that the problem will be having enough potential criteria — the problem will be getting down to the short list of essential criteria to start with. Add more later.
• Addresses Done at levels beyond what it means to call a Story done — you also need to figure out what it means to make a Sprint done, to release to an integrated-test tier, and to release to production. Quite true, but I’ll regard making concrete even just that first Story-doneness Definition of Done as progress. Baby steps.

Getting Agile also has a post on building a definition of done.

The Exercise

Here's the exercise as I envision it playing out.

Before the Exercise

Here's what I've done to prepare for the exercise.

Homework

Ask each participant to come to the meeting prepared to share one thought, idea, concern, hope, etc. You’ll need these for the icebreaker exercise, and it’s also a way to invite everyone to think about Definition of Done before the event.

Scheduling

You need 65 minutes with your team in a room. Preferably a room that feels different from your normal workspace so as to give the meeting a purpose-specific special broken-out-of-routine feel.

Supplies

• A copy of the agenda for each person. (This helps participants stay on task and understand where they are in the meeting.)
• Black Sharpies (bold writing for easy reading from a few steps back)
• ample letter size sheets of paper to which to apply those Sharpies
• masking tape or other non-damaging way of hanging your papers temporarily
• Red and green dot stickers, at least twenty of each color for each participant.

Inputs

Did you already take a shot or two at writing a Definition of Done? Do you like or at least want to think about some other Definition of Done you’ve seen? Great. Print those out and bring them to the meeting as input.

During the Exercise

The exercise consists of five facilitated structured exercises.

1. Speaking and Listening exercise (15 minutes)
2. Criteria Brainstorming exercise (15 minutes)
3. Criteria Nuancing exercise (15 minutes)
4. Criteria Selecting exercise (15 minutes)
5. Definition of Done drafting (5 minutes)

Outcome: the Product Owner will leave the meeting charged with finalizing the initial written Definition of Done, and supported in that charge with several draft written definitions that reflect the ideas worked through in the meeting.

Speaking and Listening Exercise

Purpose: frame the discussion. Get that one thing said and off your mind. Put the team into the mode of listening closely and thoughtfully to one another and summarizing.

Each participant in turn shares the one thing they want to say about the Definition of Done to frame the discussion. That could be a hope, or a goal, or a concern, or something they want to learn, or …

The catch: before sharing their one thing, each person first summarizes the one thing the previous person shared, to that previous person’s satisfaction.

Outcome: everyone gets to say something to frame the discussion. Everyone gets to feel and be heard because someone summarized what they said. Everyone heard and understood someone else’s idea, putting them into a mindset of considering others’ perspectives.

Gather Criteria

Purpose: Gather the potential criteria.

Think of a Definition of Done as a set of criteria that are true by default of all Stories when they are Done.  Every Story is Done when whatever it is about is achieved AND these criteria are true.  The Definition of Done is the stuff that is by default true of all Done stories.

The Definition of Done criteria are the criteria that ought to go without saying, the ones that it is an exceptional circumstance worth talking about when they’re not true.

In this exercise, without judgment, we brainstorm what these criteria might be.  This step isn’t about what’s hard or easy, what most valuable vs less valuable.  It’s just the criteria that could be valuable.

(If you don’t think a criteria would be valuable even if it were feasible to achieve, well, then the team needn’t bother with it.)

If your team has previous draft Definitions of Done or other inputs to this conversation, well, have them on hand to support this idea generation.

It's okay to write down criteria that ought to go without saying. (E.g. the code should compile.) Part of the point of a Definition of Done is to say what everyone thought ought to go without saying, because it might turn out that these aren't the same thing for everyone.

• 10 minutes: criteria writing: we write down potential Definition of Done criteria.
• 5 minutes: de-duplicating: we put these up on the walls, merging together closely related criteria. Try to mount them far enough apart that it’s easy to stand around them without crowding.

Gather Perspectives on the Criteria

Purpose: gather individual opinions and perspectives about the advantages and risks of potential criteria and make them easy for everyone to consider.

Now we start to make judgments about the criteria.  If a criteria would be wildly valuable or really should go without saying, that’s important to consider.  If a criteria would be really hard to implement or make people unhappy or slow velocity to a crawl, that’s important to consider too.

Using post-it notes, we note:

1. What would be valuable about including a criteria in the Definition of Done?
2. What would be hard to implement about including a criteria in the Definition of Done?

Attach these to the criteria sheets.  Merge together same-idea notes.

Do this in parallel all at once for the fifteen minutes or until the papers get stable because all the upsides and impediments have been noted.

This step doesn’t decide whether a criteria is in or out.  It writes down what we think the consequences would be of a criteria being in or out and makes those thoughts easy to see for the deciding step.

Sort Criteria

Purpose: individually decide which criteria participants would choose to include or exclude, and make those individual decisions easy for the group to see.

Mark the criteria with vote stickers

Everyone now reviews each potential criteria and decides

1. The criteria should be included in the definition of done. (Green sticker.)
2. No opinion. (No sticker.)
3. You actively want the criteria not to be included in the definition of done. (Red sticker.)

and communicates this judgment by adding a color-coded sticker to the criteria sheet.

Those decisions are helped by considering the advantages and risks everyone identified.

Use the red stickers freely. The idea is to get to an initial Definition of Done that everyone is comfortable with because the team will be committing to fulfill that Definition of Done by default on every Story. If you're not going to thrive with a Definition of Done including a particular criteria, by all means do stick a red sticker on it. Aspirational criteria can be added to the Definition of Done later through Scrum's Retrospective feature.

Do the easy filtering

Criteria with any red stickers are removed from play (someone wasn’t comfortable, and you should start from a position of strength with criteria everyone is comfortable with.) (You can revisit these vetoed criteria in future Sprint Retrospective meetings.). Avoid the temptation to try to engage with the discomfort on these criteria at this juncture. The purpose of this exercise isn't to change minds and iterate on the Definition of Done and un-stick impediments to greater excellence. Do that later. The point of this exercise is to get to a Definition of Done for Stories at all. Your new Definition of Done will immediately fail if the Team goes into it with strong misgivings.

Criteria without green stickers are removed from play (no one thought they should be included).

Do the potentially harder more nuanced filtering

Then look at the remaining criteria.  Ideally it will be evident what criteria the initial Definition of Done should include -- it’s the ones with a bunch of green stickers. You're probably looking for a bunch of green stickers -- you're probably looking for criteria with near universal consensus. The team doesn’t have to exactly all agree on where to make the cutoff between what’s in and what’s out, because there’s one more step.

Draft Definitions

Everyone writes a Definition of Done statement inspired by the criteria that seem to them to have consensus.

Rules: the drafts must only include criteria that are still In Play. If it was knocked out by a red sticker, this is not your opportunity to bring it back in. Go after it via Retrospective.

Deputize your Product Owner

Hand the definition drafts in to the Product Owner.

Why the Product Owner? Because someone has to decide and write something cogent that summarizes the decision. This someone is the Product Owner because ultimately the Product Owner is going to sign off on what Stories were really Done or not during a Sprint, and so the Definition of Done is shorthand for what he or she is typically going to expect.

After the Exercise

The Product Owner reviews the draft Definitions of Done after the meeting and picks the one that best captures what he or she wants to be meant by “Done”, perhaps word-smithing and honing it a bit (but certainly not pulling in any of those red-dotted criteria that are being initially excluded) and publishes this to the team.

Have a Definition of Done

Congratulations! You now have a written Definition of Done!

Print it out big. Put it on a wall.

Start applying it in your next Sprint

Starting with your next Sprint Planning, apply the new Definition of Done. Of course, if you’re mid-sprint, don’t change anything. The team committed to scope before this Definition of Done arrived, after all, so your current Sprint is not yet in the context of this Definition.

Before you nudge a Story over to Done, review that it meets the criteria in the Definition of Done. Use a checklist or sub-tasks or whatever you have to do.

Hold every Story to the Definition of Done -- a given Story may well be the exception that makes the rule of the Definition of Done, but that call should only be made through team consensus including Product Owner blessing.

Inspect and Adapt

Of course, just because your Definition of Done is now written down does not mean you cannot change it. In fact, now that it is written down, it is easier to change it, because now you can look at it, inspect it, and use it as a tool to discuss potential changes.

Make a point of revisiting the Definition of Done frequently in your Sprint Retrospective meetings.

If it ends up having criteria you're not able to consistently meet, acknowledge that head-on and zap the criteria. If the team finds itself wanting to do or doing something more for almost all Stories, add it to the Definition of Done.

Circle back to defining Done at other layers

So, this was intended as a minimal exercise to get to a Definition of Done for Stories, which seems like the place to start. However, there's a great point to be made that there are other steps in the Scrum process. You should have a Definition of Done for sprints, for pushing a release to the QA server, and for pushing a release to production.

In fact, there's a richer exercise to be done that brainstorms all the things that need to be done anywhere in your process, and then makes the point that if they must be done then you must do them somewhere -- so where are you going to do them? In completing a Story within the Sprint? Once at the end of each Sprint? As part of the release-to-QA process? As part of the release-to-production process? Never?

You should definitely do that -- but maybe that'll be more approachable with some experience with applying a Definition of Done to Stories.

Further reading

See also my Definition of Done bookmarks and my Scrum bookmarks more generally.

For a counter-point on why you do not need a Definition of Done, you need to be genuinely delivering Potentially Shippable software every single sprint, see Alistair Cockburn on Definition of Done.

• The Definition of Done appears in the Scrum.org Glossary, of course.
• The Scrum Guide discusses the Definition of Done, near the end. It’s rather more formal about it than I would tend to be.
• As noted above, the exercises I propose turn out to be very similar to those suggested by Mitch Lacey and Associates.
• I liked the Agile Alliance on the Definition of Done, especially their calling out downsides of over-obsessing about the criteria, importance of being open to nuancing the definition-of-done per-Story, and the significant advantages in making the Definition of Done prominently displayed and well-known, well-used.
• On differentiating the Definition of Done from Conditions of Satisfaction.
• For a longer read steeped in wider psychology-of-work concepts, try jbrains on a better path to definition of done.
• If you’re using JIRA, you might as well make the product even more complicated by manifesting your Definition of Done as a checklist on each issue.
• Definitions of Done in Practice
• I found a lot to like in Robert Galen's post on Done. He talks about a bunch of other important stuff like sprint goals and acceptance criteria. I like his thoughts about that other stuff, but I wish he was clearer about differentiating those concepts from Definition of Done. In his followup he clarifies that both the Team and the Customer (of the team) (mostly as proxied through the Product Owner, because that's what Product Owners do, after all) have a say in defining Done.

Sample Definitions of Done

Mountain Goat starting point

The Mountain Goat Software article offers this as a starting point for a Definition of Done:

• the code is well-written. That is, the team does not feel they need to immediately refactor or rewrite it.
• the code is checked in (to source control)
• the code comes with automated tests at all appropriate levels.
• the code has been either pair programmed or has been code inspected.
• the feature the code implements has been documented as needed in any end-user documentation.

Alaverdyan example

In his article on Definition of Done, Alaverdyan gives this example:

• All Acceptance Criteria of the User Story are met
• Code meets general Coding Standard (e.g. as defined in Checkstyle)
• Functional tests are performed by team members other than those working on the implementation of that feature
• Code is either reviewed or produced with a pair-programming method
• The code is covered by a minimum of 70% Unit Tests and all tests are Green
• Automated acceptance tests (Selenium) are prepared for the feature and are Green
• Integration tests of the affected areas are conducted and passed

Acknowledgements

all done cover photo : CC-BY.