Has someone ever told you something was done, but when you went to check it out, you found it was only partially done?

Before implementing Scrum in a creative department, we often had new requests that used assets from past projects. I would go look for the project files to find they were never uploaded to the drive, and now the person who worked on it is no longer with the team. I either have to chase down the files or rebuild something from scratch. 

Frustrations like these arise when there isn’t a clear definition of what is done for a Scrum team. For Scrum to work effectively, a team must have a clear answer to the following question.

What does it mean for something to be “done” in Scrum?

This answer may evolve over time, but it must always be clear and shared by the whole team. This answer is what Scrum calls the definition of done. This article will cover three essential topics to help your team define done.

• Why does done matter?
• What is the definition of done?
• How to define done as a team.
• Acceptance Criteria and the Definition of Done.

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.

‍

What is the definition of done?

The “definition of done” is an element of Scrum that brings clarity about if work is complete. It outlines the criteria for a 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.

What exactly is it that’s done?

During a sprint, no backlog item is considered completed until it has met the definition of done. Transparent inspection encourages development teams to focus on finishing work.

Every sprint, the development team produces what’s called an increment. What this is could vary based on your team. For a software development team, an increment is working code ready to be checked in and used by the customer. 

If you’re on a creative team using Scrum, it could be the completed visual assets and copy for a marketing strategy. If you are in service design, an increment could be a new element of the user journey ready to be implemented and experienced by customers.

An increment is the work product of the sprint. For the increment to be done means it is ready for action and implemented in the real world. The definition of done is important because we don’t want the marketing team to start running a campaign and discover the assets are in the wrong file format and can’t find them because nobody uploaded them to the right place. 

The Scrum Guide provides a helpful and succinct definition.

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
- The Scrum Guide

What should be in my definition of done?

There is one definition of done shared by the whole team so that everyone means the same thing when they say something is done. The definition of done should be transparently visible across all involved teams. 

For this reason, I think it is best to write the definition of done collaboratively as a team. Each person brings a unique perspective, and writing it together creates a more holistic definition and greater ownership of what you create.

Critical Elements for Your Definition of Done

• Quality Check. Were unit tests run on the code? Did the design go through a critique?
• Feedback. Did we receive feedback from the stakeholders, product owner, and user?
• Validate. Does the increment meet the goals of the user story?
• Verify. Did we meet the criteria of the feature request? Did we stay in the bounds of the constraints?
• Admin. Were the files checked in / uploaded to the correct place?
• Acceptance. Has the stakeholder/product owner formally accepted the work?
• Wrap-up. Did we send the invoice and customer survey?

The definition of done should be a specific application of these elements to your work.

Some Definition of Done Examples

Here are two examples of what a definition of done could look like:

Software Development Example

• Code reviewed
• Unit tests passed
• Security audit passed
• Success criteria met
• All code checked in
• Documentation updated
• Product owner accepts the user story

Creative Design Example

• 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.

‍

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.

‍