Definition of Done Examples for Better Increments

What This Resource Covers

This resource gives Definition of Done examples you can adapt with your Scrum Team. It starts with a short explanation of what the Definition of Done means in Scrum, then focuses on examples and why they work.

The examples show how a Definition of Done can make quality visible, reduce hidden unfinished work, and help the Scrum Team create a more reliable Increment.

What Is the Definition of Done?

According to the Scrum Guide, the Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. It is the commitment for the Increment.

That matters because a Product Backlog item can look finished while still hiding work that must happen later. Code may be written but not integrated. A page may be visible but not accessible. A workflow may work in one browser but fail in another. The Definition of Done helps the Scrum Team make those expectations explicit before the Sprint Review.

The Definition of Done also protects transparency. When the Scrum Team says an Increment is done, stakeholders should understand what that means. Done should not mean "development finished" for one person, "ready for testing" for another, and "ready to release" for someone else.

Definition of Done and Acceptance Criteria

The Definition of Done and acceptance criteria work at different levels.

Acceptance criteria usually describe conditions for a specific Product Backlog item. They help the Scrum Team understand whether that item behaves as expected. The Definition of Done describes the quality conditions the Increment must meet. It applies across items and across Sprints.

For example, an acceptance criterion for a password reset item might say that a reset link expires after 30 minutes. The Definition of Done might say that changed user flows are covered by automated regression tests, reviewed for accessibility, integrated into the main branch, and documented where support teams need to know about the change.

Both are useful. They answer different questions.

What Makes a Definition of Done Useful?

A useful Definition of Done usually has these qualities:

• It describes quality conditions that apply to the Increment.
• It is clear enough for the Scrum Team to use during the Sprint.
• It includes expectations that matter for the product, not every possible good practice.
• It is shared by everyone working on the product.
• It can be inspected and improved over time.
• It avoids hiding unfinished work behind vague wording such as "tested" or "ready".

A weak Definition of Done often sounds responsible but does not change behavior. "Code complete and tested" may look reasonable, but it leaves too many questions open. Tested by whom? At which level? Integrated with what? Reviewed against which standards?

Definition of Done Examples

1. Customer-facing web product

Context: A Scrum Team works on a customer-facing web product used across desktop and mobile browsers. The team releases changes frequently, and most problems appear when a change works in isolation but breaks the wider customer journey.

Weak version:

The feature is implemented and tested.

Better Definition of Done:

For this product, the Increment is done when:

• the change is integrated into the main product flow
• agreed automated tests pass
• the changed experience works on supported browsers and screen sizes
• accessibility expectations for the changed screens are met
• relevant error states are handled clearly
• analytics events remain consistent where the change affects measurement
• the Product Owner and Developers can inspect the Increment together before Sprint Review

Why it works:

This Definition of Done is not tied to one feature. It describes the quality bar for any Increment of a customer-facing web product. It makes integration, accessibility, testing, error handling, and measurement part of done because those are recurring quality expectations for this kind of product.

2. Mobile app

Context: A Scrum Team works on a mobile app used by customers in different network conditions. The team needs a Definition of Done that covers more than whether the app works on one developer device.

Weak version:

The app change works on mobile.

Better Definition of Done:

For this mobile app, the Increment is done when the changed behavior works on the supported operating system versions, relevant poor-network or offline scenarios have been checked, crash and error reporting are in place, agreed automated and exploratory tests have been completed, accessibility expectations for the changed screens are met, and release notes or support notes are updated when the change affects customer-facing behavior.

Why it works:

This is a product-level Definition of Done for mobile work. It does not describe a single feature. It describes recurring conditions that matter whenever the Scrum Team changes the mobile app: supported devices, network behavior, stability, accessibility, and release readiness.

3. Public API product

Context: A Scrum Team owns a public API used by partner systems. The product is not only the code behind the endpoint; it is also the contract, documentation, examples, and operational reliability that partners depend on.

Weak version:

The endpoint is complete.

Better Definition of Done:

For this public API, the Increment is done when:

• contract tests pass
• error responses are consistent with the API standard
• backward compatibility has been checked or breaking changes are explicit
• API documentation is updated
• example requests and responses are available where useful
• authentication and authorization expectations are met
• monitoring is in place for the changed API behavior

Why it works:

This Definition of Done treats the API as a product. Partners need stable behavior, understandable documentation, clear errors, and operational visibility. Those expectations apply across API changes, not just to one endpoint.

4. Regulated healthcare product

Context: A Scrum Team works on a healthcare product that handles patient-related information. The product has stronger quality expectations because defects can affect privacy, clinical workflows, and operational trust.

Weak version:

The healthcare workflow has been validated.

Better Definition of Done:

For this healthcare product, the Increment is done when:

• privacy-sensitive data is handled according to the agreed rules
• access control has been checked for the roles affected by the change
• relevant audit events are recorded
• data retention or deletion rules are respected where applicable
• clinical or operational review has happened when the change affects care workflows
• the changed behavior is documented for support or operations when needed
• the Increment is integrated into the product environment used for review

Why it works:

This Definition of Done states the recurring conditions that protect privacy, traceability, operational use, and safe inspection of the Increment. It does not try to define one healthcare feature.

5. Data and analytics product

Context: A Scrum Team works on a reporting and analytics product used for product and business decisions. Users lose trust quickly when numbers are inconsistent or definitions are unclear.

Weak version:

The dashboard has been reviewed.

Better Definition of Done:

For this analytics product, the Increment is done when metric definitions are documented, data sources are traceable, calculations have been checked against sample data, permissions are respected, loading and empty states are handled, and the changed report or chart can be understood without private explanation from the team.

Why it works:

This Definition of Done focuses on trust in the data product. A polished chart is not enough. The Scrum Team needs to make sure the data is traceable, understandable, permission-aware, and reliable enough to support decisions.

6. Internal platform product

Context: A platform team provides internal services used by other teams. The platform is valuable only if other teams can use it without constant handholding.

Weak version:

The platform capability is available.

Better Definition of Done:

For this internal platform, the Increment is done when:

• the capability is available through the agreed self-service interface
• documentation is updated for consuming teams
• versioning or migration notes are clear where behavior changes
• operational monitoring is in place
• security expectations are met
• support ownership is clear
• at least one consuming team can validate the change in a realistic usage scenario when the change affects them

Why it works:

This Definition of Done reflects what makes the platform usable by other teams. The Increment is not done just because the platform team can use it. It is done when consuming teams can understand it, adopt it, and rely on it.

7. Multi-team product

Context: Several Scrum Teams work on the same product. Each team can complete work inside its own area, but the real Increment must be integrated and usable as one product.

Weak version:

Each team has finished its stories.

Better Definition of Done:

For this product, the Increment is done when:

• work from all contributing Scrum Teams is integrated
• shared product standards are met
• product-wide tests agreed by the teams pass
• unresolved cross-team dependencies are visible
• user-facing behavior is coherent across the changed areas
• documentation, release notes, or support notes are updated where needed
• the integrated Increment can be inspected as one product

Why it works:

This Definition of Done makes the shared quality bar explicit. When several Scrum Teams work on the same product, done cannot mean that each team finished its own part. The Increment must be integrated, coherent, and inspectable as a whole.

Definition of Done Examples That Are Too Weak

Some Definitions of Done are weak because they sound complete while leaving the real quality expectations unclear.

"Tested"

Tested by QA.

This does not say what was tested, at which level, or what happens before the work reaches QA. It can reinforce the idea that quality is someone else's job.

"Code complete"

Development is complete.

This usually means the work has moved from one step to another. It does not tell the Scrum Team whether the Increment is usable, integrated, documented, secure, or ready to inspect.

"Ready for release"

Feature is ready for release.

This may be useful as a short label, but it hides too much unless the team has already defined what release readiness means for the product.

"All acceptance criteria met"

The Product Backlog item meets all acceptance criteria.

This may be necessary, but it is not enough. Acceptance criteria are item-specific. The Definition of Done should also cover quality expectations that apply to the Increment.

"Approved by the Product Owner"

Product Owner has signed off.

The Product Owner's feedback matters, but approval alone is not a Definition of Done. The Scrum Team still needs shared quality criteria that make the state of the Increment transparent.

How to Use These Examples With Your Scrum Team

Start by looking at the problems your team actually sees. Where does unfinished work hide? Where do defects appear late? Where does integration hurt? Where do stakeholders discover that "done" did not mean what they expected?

Then write the Definition of Done in product language, not only technical language. A good conversation often starts with questions like these:

1. What must be true before we can call an Increment done?
2. Which quality expectations apply to every Increment?
3. Which expectations depend on the product area or risk level?
4. What do we keep discovering too late?
5. What does the organization already require as a minimum standard?
6. If several Scrum Teams work on the same product, what must be shared across all of them?

Keep the Definition of Done small enough to use. If it becomes a long document that nobody reads during the Sprint, it will not help much. Start with the expectations that protect transparency and product quality, then inspect and improve it over time.

Related Training

Agile Way offers public and private Professional Scrum Product Owner courses. The Definition of Done matters for Product Owners because it changes how Product Backlog items, Sprint Reviews, release expectations, and stakeholder conversations are understood.

If you are preparing for certification, you may also find How to Pass the PSM I Certification Exam and How to Pass the PSPO I Certification Exam useful.

Summary

Definition of Done examples are useful when they make quality explicit. A strong Definition of Done:

1. describes the quality state required for the Increment
2. applies across Product Backlog items, not only to one item
3. helps the Scrum Team reduce hidden unfinished work
4. supports transparency with stakeholders
5. can be inspected and improved as the product changes

The best Definitions of Done help the Scrum Team move from "we finished our part" to "the Increment meets the quality measures required for this product".