Definition of Done in Scrum

The Definition of Done is a Scrum Team’s shared understanding of what must be true before work can be considered complete.

A good Definition of Done makes quality visible. It helps the team, Product Owner, and stakeholders know whether a product backlog item is really done, whether an increment is usable, and whether the team’s progress is honest.

Without a Definition of Done, one person may mean “coded,” another may mean “tested,” and another may mean “ready to release.” Scrum needs more clarity than that.

Who This Page Is For

This page is for Scrum Teams that want a clearer, more useful standard for completed work.

It is especially useful for:

Developers who want a shared standard for finishing product backlog items
Product Owners who need confidence that completed work is usable
Scrum Masters helping teams improve transparency and quality
Teams that carry unfinished work from sprint to sprint
Teams confused about the difference between Definition of Done and acceptance criteria

What This Page Covers

This page explains what Definition of Done means in Scrum, why it matters, what belongs in it, how it relates to the increment, and how it differs from acceptance criteria.

It also covers how the Definition of Done can improve over time, how nonfunctional requirements can become part of it, and how to avoid common mistakes that make “done” less meaningful.

What Is the Definition of Done?

The Definition of Done is the set of criteria that must be met before work can be considered complete.

In Scrum, the Definition of Done is tied directly to the increment. Each sprint should produce a usable increment of product. The Definition of Done describes the quality and completion standard that increment must meet.

For a software team, the Definition of Done might include things such as:

Code has been written and checked in
Code meets the team’s coding standards
Code has been reviewed or pair programmed
Automated tests have been added and are passing
Important manual tests have been completed
The work has been integrated with the rest of the product
Necessary documentation has been updated
The product works in the supported browsers, devices, or environments

That list will vary by team and product. A medical device team, a financial services team, a mobile app team, and a marketing team will not have identical Definitions of Done.

Each team’s list will differ. What matters is that everyone shares the same honest standard for what done means.

Why Definition of Done Matters

Definition of Done matters because Scrum depends on inspecting real progress.

If a team says a product backlog item is done, but testing, integration, security review, documentation, or browser support remains unfinished, the team has not created as much progress as it appears. The unfinished work is still there. It is just hidden.

That hidden work creates problems later:

Sprint Reviews become less useful because stakeholders are inspecting work that is not truly usable.
Velocity becomes misleading because the team is taking credit for incomplete work.
Forecasts become less reliable because “done” does not mean the same thing each sprint.
Quality problems accumulate because finishing work is repeatedly deferred.
Teams start adding hardening sprints, stabilization sprints, or late testing phases to compensate.

The Definition of Done helps prevent that. It gives the team a common standard for finishing work inside the sprint rather than pushing unfinished work into the future.

A team does not need a perfect Definition of Done on day one. But it does need an honest one.

Definition of Done and the Increment

Scrum has three artifacts: the product backlog, the sprint backlog, and the increment. Each artifact has a commitment. For the increment, that commitment is the Definition of Done.

The Definition of Done is more than a checklist sitting somewhere in a tool. It is the standard the team uses to decide whether the increment is complete enough to inspect.

The increment should be usable. That does not mean the Product Owner must release it publicly every sprint. It means the work is integrated, tested, and complete enough that it could be released if the Product Owner chose to do so.

That distinction matters.

A team may produce a done increment every sprint and release less often for business, regulatory, marketing, or operational reasons. But if the increment is not done, the team is delaying learning and building up unfinished work.

Definition of Done vs. Acceptance Criteria

Definition of Done and acceptance criteria answer different questions.

Acceptance criteria describe what must be true for a specific product backlog item to satisfy the Product Owner or stakeholder need. They vary from item to item.

For example, a backlog item that lets users search for wine might include acceptance criteria such as:

Users can search by type of wine
Users can search by price range
Users can search by rating

A backlog item that lets users pay for items in a shopping cart would need different acceptance criteria:

The buyer is charged the correct amount
Shipping charges are calculated correctly
If a credit card is declined, the buyer is notified and can update the card

Those criteria are specific to the item.

The Definition of Done contains things that apply to all, or nearly all, product backlog items. For the same wine-shopping site, the Definition of Done might include:

The work has been tested
Code has been checked in
Automated tests have been added where appropriate
The site works in supported browsers
The work has been integrated into the product

You could write those same completion standards into every backlog item, but that would be repetitive and easy to forget. Instead, common completion standards belong in the Definition of Done.

A simple way to think about it is this:

Acceptance criteria answer, “What must this specific item do?”
Definition of Done answers, “What must be true of completed work on this product?”

Both matter. A product backlog item is not done until it satisfies its item-specific acceptance criteria and the team’s broader Definition of Done.

What Belongs in a Definition of Done?

A Definition of Done should include completion standards that apply broadly to the team’s work.

For a software team, useful categories often include:

Code and Design Quality

The work should meet the team’s coding, design, architecture, and maintainability standards.

That does not mean every design decision must be perfect. It means the team should not call work done if everyone already knows it needs immediate cleanup before it can safely be used.

Testing

The work should be tested at the appropriate levels.

That may include unit tests, service-level tests, UI tests, exploratory testing, performance testing, security testing, or other forms of validation. The exact mix depends on the product.

Automated tests are often an important part of a strong Definition of Done. If the team adds new functionality but repeatedly postpones automated tests, the cost of testing climbs and the team eventually slows down.

Integration

The work should be integrated into the product.

A feature that works only on one person’s machine or in an isolated branch is usually not done. Integration problems are real work. They should not be hidden until later.

Documentation

Documentation should be updated when the work requires it.

That might mean user-facing help, release notes, API documentation, support documentation, internal technical notes, or training materials.

Nonfunctional Requirements

Some nonfunctional requirements belong in the Definition of Done once the product has come into compliance with them.

For example, suppose a site supports Chrome, Edge, and Safari. The team later decides to support Firefox. The first step is to bring the product into compliance.

A team might create a backlog item such as “As a Firefox user, I want the site to work correctly in my browser.” Once the team has done the work to support Firefox, the Definition of Done can be updated so future work continues to support Chrome, Edge, Safari, and Firefox.

This same pattern can apply to performance, accessibility, localization, privacy, security, branding, supported devices, or other product-wide qualities.

Do the work to come into compliance. Then update the Definition of Done so the product stays in compliance.

What Does Not Belong in a Definition of Done?

A Definition of Done should not become a dumping ground for every detail the team cares about.

Item-specific behavior belongs in acceptance criteria. For example, “Users can search by price range” belongs with a search story, not in the Definition of Done.

One-time project tasks do not usually belong in the Definition of Done either. “Migrate the billing database to the new vendor” is work to be planned, refined, and completed. It is not a broad completion standard that applies across future backlog items.

A Definition of Done should be broad enough to apply repeatedly, but specific enough to guide real decisions.

Weak examples include:

Work is high quality
Testing is complete
Documentation is done
Product Owner is happy
No major problems remain

Those are too vague. They sound good, but they do not help the team make consistent decisions.

Stronger examples include:

Code has been checked in to the shared branch
Appropriate automated tests have been added and pass
The work has been reviewed by another team member
The feature works in Chrome, Edge, Safari, and Firefox
User-facing documentation has been updated when behavior changes
No critical or high-severity defects remain open for the item

The stronger examples are easier to inspect.

A Definition of Done Example

Here is a practical example for a software product team:

For a product backlog item to be done:

- The item satisfies its acceptance criteria.
- Code has been checked in.
- Code follows the team’s coding standards.
- The work has been reviewed or pair programmed.
- Appropriate automated tests have been added and pass.
- Important exploratory or manual tests have been completed.
- The work is integrated into the product.
- The product works in supported browsers and environments.
- User-facing documentation has been updated when needed.
- No known critical or high-severity defects remain for the item.

This is only an example. A real team should adapt the list to its product, risks, technology, regulatory environment, and current capability.

A marketing team would need a different Definition of Done. For example:

For a campaign asset to be done:

- Copy has been reviewed and approved.
- Design has been reviewed and approved.
- Links, dates, offers, and prices have been checked.
- The asset follows brand standards.
- Required stakeholders have approved it.
- The asset has been scheduled or published in the correct system.

Different product, different work, different Definition of Done. The principle is the same: make the completion standard explicit.

Start Where the Team Can Be Honest

Some teams make their Definition of Done too ambitious.

They write the Definition of Done they wish they had, not the one they can meet. That can be discouraging. Worse, it teaches the team to ignore the Definition of Done.

A better approach is to start with a Definition of Done the team can actually meet, then strengthen it over time.

For example, a team that relies heavily on manual testing may not be able to add full automated regression coverage immediately. But the team might add a smaller standard: every new feature includes appropriate automated tests from this point forward.

That stops the problem from getting worse. The team can then gradually pay down the older testing debt.

This pattern is useful for many quality improvements:

Stop making the problem worse.
Stay current on new work.
Pay down the old debt over time.

The Definition of Done can help with all three.

Definition of Done and Estimating

A team’s estimates should include everything needed to meet the Definition of Done.

If the Definition of Done says new work needs automated tests, the effort to create those tests is part of the estimate. If the Definition of Done says documentation must be updated when user-facing behavior changes, that work belongs in the estimate too.

This matters because teams sometimes estimate only the coding. Then testing, integration, documentation, review, or cleanup appear later as surprises.

Those are not surprises. They are part of doing the work.

A product backlog item should not count toward velocity unless it meets the Definition of Done. Giving partial credit for almost-done work makes progress look better than it is and weakens the value of velocity as a planning signal.

Who Creates the Definition of Done?

The Scrum Team should understand and use the Definition of Done together.

The Developers are especially important because they know what it takes to create a usable increment. The Product Owner cares because the Definition of Done affects release decisions, stakeholder expectations, and product quality. The Scrum Master helps the team inspect and improve the Definition of Done as part of improving Scrum.

Organizational standards may also apply. For example, an organization may require certain security, compliance, accessibility, or documentation standards. The team’s Definition of Done should include those standards when they apply.

The team may also add product-specific standards beyond the organizational minimum.

When to Revisit the Definition of Done

A Definition of Done should not change every day, but it should improve.

Good times to revisit it include:

The team repeatedly carries unfinished work into the next sprint
Sprint Reviews reveal work that is not really usable
Defects keep appearing after work was called done
Testing or integration regularly happens late
The team adds support for a new browser, platform, device, language, or market
The organization adds new security, privacy, accessibility, or compliance expectations
Retrospectives identify recurring quality problems
The team has improved its capability and can raise the standard

The Sprint Retrospective is often the right place to discuss changes. The team can ask, “What would we need to add to our Definition of Done to prevent this problem from recurring?”

Do not make the Definition of Done so heavy that the team cannot use it. But do keep improving it as the team learns.

Common Problems with Definition of Done

Done Means Different Things to Different People

This is the problem the Definition of Done is meant to solve.

If “done” means coded to one person, tested to another, and releasable to someone else, the team will have conflict and hidden unfinished work.

The Definition of Done Is Too Weak

A weak Definition of Done lets the team declare success too early.

If the team regularly says work is done while testing, integration, review, or documentation remains, the Definition of Done is not providing enough transparency.

The Definition of Done Is Too Ambitious

A Definition of Done the team cannot meet will be ignored.

It is better to be honest about today’s standard and improve it than to write an impressive standard that no one follows.

The Team Confuses Definition of Done with Acceptance Criteria

Acceptance criteria vary by backlog item. The Definition of Done applies broadly.

Putting item-specific details into the Definition of Done makes it noisy and less useful. Repeating broad completion standards in every backlog item makes backlog items harder to write and maintain.

Nonfunctional Requirements Stay Vague

“Fast,” “secure,” “accessible,” and “easy to use” are not enough.

Nonfunctional requirements need concrete standards. When they apply broadly and the product has come into compliance, they can become part of the Definition of Done.

The Definition of Done Never Improves

A team’s first Definition of Done is rarely its best.

If the team’s skills, tools, product, and risks change, the Definition of Done should change too. For more detail, see Definition of Ready: What It Is and Why Its Dangerous.

Before You Call Work Done

Before a team calls a product backlog item done, it should be able to answer these questions:

Does the item satisfy its acceptance criteria?
Does it meet the team’s Definition of Done?
Has the work been integrated into the product?
Has the right testing been completed?
Have required reviews happened?
Have relevant nonfunctional requirements been met?
Has documentation been updated where needed?
Is there any known unfinished work being hidden by the word done?
Would the Product Owner be able to make a release decision based on this work?

Use these questions to keep “done” honest without turning the Definition of Done into bureaucracy.

FAQ

What is definition of done in Scrum?

Definition of Done is the Scrum Team’s shared standard for what must be true before work can be considered complete.

It describes the quality and completion criteria that product backlog items and the increment must meet.

Is definition of done the same as acceptance criteria?

No. Acceptance criteria apply to a specific product backlog item. Definition of Done applies broadly across the team’s completed work.

A backlog item must satisfy both its acceptance criteria and the team’s Definition of Done before it is done.

Who owns the definition of done?

The Scrum Team should understand and use the Definition of Done together.

Developers rely on it to complete work. The Product Owner relies on it when making product and release decisions. The Scrum Master helps the team inspect and improve it.

Can the definition of done change?

Yes. A good Definition of Done should improve as the team learns, as the product changes, and as the team’s technical capability increases.

The team should avoid changing it casually during a sprint to make unfinished work appear done.

Does done mean released?

No. Done means the work meets the Definition of Done and is usable.

Released means the Product Owner or organization has chosen to make that work available to users or customers. A team can create a done increment every sprint without releasing publicly every sprint.

Should automated tests be part of the definition of done?

Often, yes.

The exact testing standard depends on the product and team, but automated tests are frequently an important part of keeping work done and preventing manual testing debt from growing.

Should nonfunctional requirements be in the definition of done?

Some should be, especially when they apply broadly across the product.

The team may first need to create product backlog items to bring the product into compliance. Once that happens, the Definition of Done can be updated so future work keeps the product in compliance.