What is the definition of done in Scrum?

Examples of Scrum definition of done.

September 3, 2023
Two people leaping for joy

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.

New to Scrum? The Scrum meeting checklist has all the details you need to run effective Scrum meetings.

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 or PBI 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.

Leaning Scrum for the first time can be a bit overwhelming. There are many new terms and concepts in Scrum.

Well we’re here to help.

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.

Related Guides

No items found.

Action Plan

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.

Frequently Asked Questions

Scrum elements

What is the definition of done?

The definition of done is a list of what must be true to consider a PBI done. The whole team creates and agrees to what is in the definition of done and is updated as needed for the team to function effectively. 

Learn to use the definition of done and explore acceptance criteria vs definition of done.

What is the increment in scrum?

It is the next complete piece added to build the product. The increment is complete in the sense that it should be ready to release to the end-user even if the team chooses to wait.

Learn more about incremental and iterative development or explore the essential Scrum glossary.

Scrum design

What are the three pillars of Scrum?

Scrum is founded on three essential pillars, and each leads the team to ask a critical question.

  1. Transparency. How does this make things more visible?
  2. Inspection. Where does this create space to evaluate?
  3. Adaptation. When does this encourage growth?

Learn how to apply the three pillars of Scrum and then explore the most common terms in a Scrum glossary.

What are the values of Scrum?

There are five values critical to the practice of Scrum: commitment, courage, focus, openness, and respect.

  1. Commit to achieving the goals of the Scrum Team.
  2. Courage to do the right thing and work on challenging problems.
  3. Focus on the Sprint's work and the Scrum Team's goals.
  4. Open about all the work and the challenges with performing the work.
  5. Respect each other to be capable, independent people

Learn how to align Scrum values with your organization and then explore the most common terms in a Scrum glossary.

What is the sprint goal in scrum?

The sprint goal encapsulates the product owner’s vision into a concrete statement for the development team to measure the sprint against. The sprint goal provides a theme for the sprint’s work helping the team see how all the parts come together. 

Learn more about the role of the sprint goal in scrum and explore the essential Scrum glossary.

Scrum backlog

What is the backlog in Scrum?

There are actually two backlogs, the product backlog and the sprint backlog. They each contain the definitive list of work to be done. The product owner keeps the backlog ordered by priority. 

Learn to use the backlog in Scrum and check out the sprint backlog vs product backlog in Scrum.

How are the product backlog and sprint backlog different?

The product backlog prioritizes the features needed in the product. It is a singular visible source of requirements for the product.

The sprint backlog represents the work to do in a given sprint. It is a definitive list of all the scrum team is being asked to produce for the sprint. 

Learn more about the sprint backlog vs product backlog in Scrum.

What is a PBI (product backlog item)?

Each item in the backlog represents precise work and value to deliver. Often these PBIs are written using both user stories and acceptance criteria. The PBIs are what gets refined during the backlog refinement session, and if one is too large, it may be broken down into smaller PBIs.

Learn more about how backlogs are used in scrum, the sprint backlog vs product backlog in Scrum and explore the essential Scrum glossary.

What is the Scrum sprint backlog?

The Scrum sprint backlog is a prioritized list of items from the product backlog that the development team plans to complete during the upcoming sprint.

It is a plan for the Sprint and is created during the Sprint Planning meeting where the Development Team decides on how to build the functionality that meets the Sprint Goal. The Sprint Backlog typically includes user stories, bugs, technical work, and other items that the development team needs to work on during the sprint. Each item in the Sprint Backlog has a clear definition of done, so the team knows when the item is considered complete.

The Development Team is responsible for creating and updating their Sprint Backlog throughout the Sprint, making sure they are on track to meet the Sprint Goal. The Sprint Backlog is a working document that helps the Development Team visualize their progress and make any necessary adjustments to their plan as they go along. The Sprint Backlog is also transparent, allowing stakeholders to see what work is being done during the Sprint.

Learn more about the backlogs of Scrum.

What is the Scrum product backlog?

In Scrum, the product backlog is a prioritized list of features, bugs, technical work, and other product-related items that need to be addressed by the development team.

It serves as a single source of truth for what needs to be done on the product.

The items in the product backlog are ordered based on their importance to the product owner and the value they bring to the end-user. As the project progresses, the product backlog is constantly updated to reflect new priorities, changes in requirements, and feedback from stakeholders.

The product backlog is a living document that evolves throughout the project's lifecycle. It provides transparency and enables collaboration among all members of the Scrum team.

Learn more about the backlogs in Scrum.

Acceptance criteria

What's an example of acceptance criteria?

Acceptance criteria is structured using the template

  • Given that [context allowing me to take an action]
  • When [I take the action]
  • Then [a result occurs indicating success or failure]

Here are 3 examples:

Checkout process functionality

  • Given that I’ve added all the items to my cart and I’m logged in,
  • When I click the check out button,
  • Then the checkout page loads with all my payment and shipping information preloaded.

Advertising campaign

  • Given that someone fits our ideal customer persona,
  • When they search for keywords we’re targeting,
  • Then a link to a compelling offer is displayed above the fold.

Marketing campaign (Did you know you could use Scrum for marketing)

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

See more acceptance criteria examples and learn to write how to create your own or learn other essential scrum terms.

What is acceptance criteria in scrum?

Acceptance criteria is written using the following structure:

  • Given that [context allowing me to take an action]
  • When [I take the action]
  • Then [a result occurs indicating success or failure]

Learn more about how acceptance criteria is used in Scrum and explore the essential Scrum glossary.

How to write an acceptance criteria statement?

Acceptance criteria is broken down into three parts.

  • Given that [context allowing me to take an action]
  • When [I take the action]
  • Then [a result occurs indicating success or failure]

Learn more about templates for writing acceptance criteria or learn other essential scrum terms.

How are acceptance criteria and user stories different?

A user story focuses on the identity, goals and motivations of the user you’re designing for. It emphasizes the why of the new functionality.

Acceptance Criteria focuses on the action taken by the user to meet their goal. It highlights the what of the new functionality.

See more acceptance criteria examples and learn to write acceptance criteria or learn other essential scrum terms.

How are acceptance criteria and the definition of done different?

Acceptance criteria is specific to an individual task, but the definition of done applies to all work done by a team. Acceptance criteria answers the question, “What will be true when this task is completed.” The definition of done answers the question, “What are we committing to do every time we complete a task?”

See more examples and learn to write acceptance criteria or learn other essential scrum terms.

Scrum User Stories

What is a user story?

They keep the team focused on the value they create for the end-user and are written using the following format:

  • As a… [user]
  • I want to… [goal]
  • So that I can… [motivation] 

See examples of user stories to learn to write your own and explore the essential Scrum glossary.

What is acceptance criteria in scrum?

Acceptance criteria is written using the following structure:

  • Given that [context allowing me to take an action]
  • When [I take the action]
  • Then [a result occurs indicating success or failure]

Learn more about how acceptance criteria is used in Scrum and explore the essential Scrum glossary.

How are acceptance criteria and user stories different?

A user story focuses on the identity, goals and motivations of the user you’re designing for. It emphasizes the why of the new functionality.

Acceptance Criteria focuses on the action taken by the user to meet their goal. It highlights the what of the new functionality.

See more acceptance criteria examples and learn to write acceptance criteria or learn other essential scrum terms.

What's an example of acceptance criteria?

Acceptance criteria is structured using the template

  • Given that [context allowing me to take an action]
  • When [I take the action]
  • Then [a result occurs indicating success or failure]

Here are 3 examples:

Checkout process functionality

  • Given that I’ve added all the items to my cart and I’m logged in,
  • When I click the check out button,
  • Then the checkout page loads with all my payment and shipping information preloaded.

Advertising campaign

  • Given that someone fits our ideal customer persona,
  • When they search for keywords we’re targeting,
  • Then a link to a compelling offer is displayed above the fold.

Marketing campaign (Did you know you could use Scrum for marketing)

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

See more acceptance criteria examples and learn to write how to create your own or learn other essential scrum terms.

What are story points?

They aren’t absolute measurements like hours or days but measure the amount of work a PBI takes relative to other PBIs. Typical measurements include using Fibonacci numbers or t-shirt sizes.

Learn to use story points and explore the essential Scrum glossary.

Ready to level up your company? Get in touch today!