What is the definition of done in Scrum?

Why does done matter?

“I’m about 80% done…” Maybe you’ve been the one to say this, or maybe it’s the typical response you get when asking a team member about progress on a task or project. It’s amazing how common it is for things to hover around “80% done” for an unreasonable amount of time. This happens when we aren’t clear about what we mean when saying “done.”

There are a lot of challenges caused when the finish line for work is unclear or unreached. Two I’d like to highlight are the issues of cognitive load and progress debt.

Cognitive load

Research has shown that multitasking is really just task switching. When we continue to add work without bringing past work to completion, we add to the cognitive load individually and collectively for our teams and organizations. The cost is paid with greater difficulty focusing, getting into a flow, and doing deep work.

Progress debt

Most of our future work depends on our current and past work. To make progress, teams need the previous work to be satisfactorily completed. But when “complete” or “done” is an ambiguous term, team members begin to distrust work that’s been done leading to delay or rework. 

When we aren’t sure what has indeed been done, it’s hard to know what can now be started. Moral begins to be impacted when it’s challenging to see measurable progress.

How to define done as a team.

Teamwork and collaboration depend on trust. A shared definition of done supports trust between team members on shared work. But there are plenty of challenges to living this out. 

What do I do if someone says something is done but it isn’t

This happened to me recently. An intern had finished up her year and all her assigned work was marked as done. A week later I went to find some assets from her last project. I opened the designated folder on Google Drive and… it was empty. No deliverables, no source files, nada. The task was set to “done” but clearly it wasn’t done.

When a team works together to create and maintain the definition of done, it essentially becomes a shared contract among team members of how we commit to working together. 

So when someone marks something as done that doesn’t meet the definition of done, it’s the team who inspects and holds them accountable. While the Scrum Master can remind the team of the definition of done, the real power is in peer accountability.

As a scrum master, I cultivated my team's “we” language. What work are “we” selecting this cycle? How are “we” going to complete that this week? Do “we” feel this is done? By investing in the “we” language we cultivate shared ownership on the team so that if you say work is done but it isn’t, then that affects me.

The temptation to say it’s done.

Unfortunately, labeling something done that isn’t is more common than it should be. But why does it happen? Why are we tempted to say something is done when it’s not?

• We’re done. Let’s be honest some projects are exciting and life-giving, and some are not. So if we feel like we’re done, then the project should also be.
• We’ve got other stuff we “need” to work on. When we’re overwhelmed, we can be tempted to say it’s done and move on. But we selected the work as a term and are accountable as a team. I can’t just make this choice for myself.
• We’re optimistic. We’re almost done and we’ll do those last few things this afternoon. So let’s just check it off as done. It feels so good, what the harm? We had good intentions of uploading the files or sending the survey but then…(insert emergency of the day) happened and we totally forgot. This is why we don’t check things off as done until they are actually done.

Working the Definition of Done into Your Rhythm

Completed work should come up as a part of your daily standup. So the whole team hears when work is “done.” If someone thinks it doesn’t meet the definition they should speak up. It is often just an oversight rather than an attempt to pass off incomplete work.

At the end of a sprint, the team evaluates how they work during the Sprint Retrospective. If there is a common issue with their work, do they need to add additional criteria to the definition of done? 

If they consistently miss one of the criteria, is there a change they can make to their workflow or process to fix it? Teams can continue to adapt their definition of done to meet the requirements of the project and organization.

The definition of done can change over time and should serve both the needs of the team and the larger organization. If multiple scrum teams are working on shared projects, they need to have visible matching definitions of done.

Acceptance Criteria and the Definition of Done.

The Definition of Done is another Scrum concept that many people ask how it compares to acceptance criteria. When it comes to using Scrum to get stuff done, Acceptance Criteria and the Definition of Done both play important roles

How is acceptance criteria different than the definition of done in Scrum?

The definition of done is also a criterion. It outlines what must be true for any product backlog item to be considered “done.” This criterion is broad and flexible enough to be applied to all backlog items yet concrete and specific enough for it to be clear whether or not it has been met.

So the definition of done applies to all work done by a team and answers the question, “What are we committing to do every time we complete a task?”

In comparison acceptance criteria applies to a single task or product backlog item and answers the question, “What are we committing to do on this specific task?”

So you see acceptance criteria is specific to a given task and definition of done applies to all tasks. So every task should have both acceptance criteria and definition of done defining what it means for the task to be done. 

How do acceptance criteria and the definition of done work together?

Have you ever been on a project where everything seemed mostly done, but nothing seemed really done?

Acceptance criteria and the definition of done work together to tackle the challenge of work staying undone. Because it’s so frustrating when you expected something to be done, and it’s not. Or someone says it’s 80% done, but a week later and it’s still 80% done. 

The truth is… It’s either done or it’s not.

Acceptance criteria and the definition of done are two tools to help combat the challenge of undone work. When both are included on a given task, there should no longer be any ambiguity. If the task's acceptance criteria has been met and the team's definition of done requirements have been met, then the task is done. Anything short of that and it's not done yet.

Examples of acceptance criteria and the definition of done being used together.

Let’s look at an example of acceptance criteria and definition of done for a creative team delivering marketing collateral.

Will use the same acceptance criteria from above for a marketing campaign.

• Given that a customer is already receiving email communications,
• When they visit the site and engage content related to product X,
• Then they will be automatically subscribed to nurturing campaign highlighting that product.

So you can see this acceptance criteria is specific to a given task. If at the end of the sprint this isn’t how the functionality works, then the task isn’t done. Period.

Now how might the definition of done play a role here?

That same Scrum marketing team my have this as their definition of done.

• User testing performed and results shared with the client.
• At least one demo performed during the sprint for the client.
• Success criteria met
• Assets delivered to the client.
• Assets and design files archived in the proper folder.
• Product owner accepts the user story.
• Invoice submitted.
• Customer survey sent.
• Evaluation scheduled.

Remember the definition of done is the commitment of the whole Scrum team to every task. So for this to be called done it has to meet all the definition of done criteria as well. 

This can seem a little OP at first, but look back through the list. These are basic things that are just part of doing the job. However by explicitly stating them and committing to them as a team you can change the team culture around getting stuff done.

Next steps​ for defining done and learning Scrum.

It feels terrific to check something off the list, and having a clear definition of done allows you to check it off with confidence.

I hope this article helped you learn how to use the definition of done to support collaboration on your teams. If you want to learn more about Scrum in general, check out my What is Scrum? A Guide for Everyday People to Learn Scrum. If you have more questions, please feel free to reach out on LinkedIn.

Still not sure about your next step with Scrum? I offer a couple of free coaching sessions each month. You can signup for a free 1-hour coaching session, and we can work together to identify a good next step for you.