Definition of Done: Examples From Real Teams

Without one, "done" is negotiated per item and per person. A developer means the code works locally. A tester means it passed. A product owner means the customer can use it. Everyone reports done, and the sprint review reveals three different definitions.

This guide covers what a definition of done is, worked examples for five different team types, how to write your first one, and how to evolve it without it becoming an unread wall of text.

Quick answer: A definition of done is a short, shared list of conditions every piece of work must meet before the team calls it complete — code reviewed, tests written, documentation updated, deployed — and it applies to all work equally, unlike acceptance criteria which are specific to one item. Its purpose is to make "done" mean the same thing to everyone, every time.

What a Definition of Done Actually Is

A definition of done is the team's shared quality bar — the conditions that apply to every item before it counts as complete — agreed by the team and visible to everyone.

The important word is *every*. Anything applying to only some items is acceptance criteria, not a definition of done.

A shared quality bar, not a checklist of tasks

A definition of done is not the steps required to build something. It is the state the work must be in before anyone claims it is finished.

The distinction matters practically. "Write the API endpoint" is a task. "All new endpoints have integration tests" is a done criterion. The first describes the work; the second describes the standard the work must meet regardless of what it was.

How it differs from acceptance criteria

Acceptance criteria are specific to one story: what this particular feature must do to satisfy its purpose. They change with every item.

The definition of done is constant. It applies to the login feature, the reporting page and the bug fix identically. A story is complete when it satisfies both its own acceptance criteria and the team's definition of done — the two work together rather than competing.

Why it belongs to the team, not the manager

A definition of done imposed from outside becomes a compliance exercise. Teams route around criteria they did not agree to, particularly under deadline pressure.

The team writes it, because the team must be able to meet it every sprint. A manager can absolutely raise the bar over time by asking what would need to change to add a criterion — but the commitment has to be the team's, or it will not hold when a release date is close.

Definition of Done Examples by Team Type

Team type Typical criteria count Emphasis Hardest criterion to hold

A small web development team

Review, tests, deployed Automated test coverage

A mobile app team

Device testing, store readiness Testing across device matrix

A data and analytics team

Validation, documentation Reproducibility

A marketing content team

team 5–6 Review, brand, accessibility Accessibility checks Regulated environment 10–14 Traceability, sign-off Audit documentation

Worked Examples

A small web development team A realistic definition for a team of five shipping continuously:

- Code peer-reviewed and approved by one other developer - Unit tests written for new logic, and the full suite passes - Merged to main with no failing checks - Deployed to staging and manually verified - Acceptance criteria confirmed by the product owner - No new accessibility errors introduced - Relevant documentation updated Why it works: every line is objectively checkable, and the whole list is short enough to hold in memory.

A mobile app team Mobile adds constraints that web teams do not face:

- Code reviewed and merged - Unit and UI tests pass on the CI pipeline

- Verified on the current minimum supported OS version - Tested on at least one small-screen and one large-screen device - No new crash reports in the internal build - Analytics events implemented and firing correctly - Strings externalised for localisation - Release notes drafted Why it works: it acknowledges the device matrix and the fact that shipping is gated by a store review, so quality problems are expensive to fix after release.

A data and analytics team Data work needs different guarantees:

- Query or pipeline peer-reviewed - Output validated against a known-good source - Row counts and null rates checked against expectations - Pipeline runs successfully end to end in staging - Data dictionary and lineage documentation updated - Dashboard changes reviewed by the requesting stakeholder Why it works: it focuses on correctness and reproducibility, which are the failure modes that matter in data work.

A marketing content team The concept applies well outside software:

- Draft reviewed by one other team member - Brand and tone guidelines checked - All claims fact-checked with sources recorded - SEO fields complete: title, meta description, slug, alt text - Images optimised and licensed appropriately - Legal review completed where the content makes product claims Why it works: it prevents the recurring rework caused by content reaching publication with missing metadata or unverified claims.

A regulated or enterprise environment

Regulated work carries obligations that must appear in the definition:

- Code reviewed with reviewer recorded in the ticket - Automated tests pass with coverage above the agreed threshold - Security scan completed with no high-severity findings - Change request raised and approved - Traceability recorded from requirement to test to release - Documentation updated in the controlled repository - Business sign-off recorded against the ticket Why it works: the audit trail is built into the definition rather than assembled retrospectively before an inspection.

How to Write Your First Definition of Done

Build your first definition from the problems you already have, include only criteria that apply to every item, and phrase each line so it can be objectively verified.

Start from what already goes wrong

Rather than copying a template, list the last ten things that were called done and then turned out not to be. Missing tests. Not deployed. Broke on mobile. Nobody told support.

Each recurring failure becomes a candidate criterion. This produces a definition that addresses your actual problems rather than a generic list that reads well and changes nothing.

Keep it to what applies to every item

If a criterion applies to some work but not all, it does not belong here. "Load tested" might apply to backend changes and not to copy edits — that is acceptance criteria for a category of work.

Keeping the list universal is what makes it usable. A definition with exceptions requires judgement about which apply, and that judgement is exactly the ambiguity you were removing.

Make each line objectively checkable

"Code is high quality" cannot be verified. "Code reviewed and approved by one other developer" can.

Every criterion should be answerable yes or no by someone who was not involved in the work. If two people could reasonably disagree about whether a criterion is met, rewrite it until they cannot.

Evolving It Over Time

Add criteria one at a time, review the definition in retrospectives, and be explicit about standards you want but cannot yet meet.

Add one criterion at a time

A team that adds five demanding criteria simultaneously will miss its sprint commitment and quietly abandon the definition.

Add one, hold it for two or three sprints until it becomes automatic, then consider the next.

Raising the bar slowly is the only approach that survives contact with delivery pressure.

Review it in the retrospective

Once a quarter, look at the definition during a retrospective. Ask two questions: is anything on this list being skipped, and is anything missing that keeps causing problems?

Criteria that are routinely skipped are worse than absent, because they teach the team that the definition is optional. Either enforce them or remove them honestly.

Handle the criteria you cannot meet yet

Some teams want automated test coverage or automated deployment but do not have the infrastructure yet.

Keep a separate, visible list of aspirational criteria with the blocker noted against each. This is more useful than either pretending the standard exists or ignoring it — it makes the gap explicit and gives you a queue of improvement work with a clear justification.

Common Definition of Done Mistakes

The three failures are writing aspirations rather than commitments, producing a list too long to read, and allowing "done" to be interpreted individually.

Writing aspirations instead of commitments

A definition containing standards the team cannot currently meet is not a definition of done — it is a wish list, and everyone knows it. The first time a deadline approaches, the whole thing is disregarded.

Only include what you will genuinely hold to every sprint. A short honest list has authority; a long aspirational one does not.

Making it so long nobody reads it

Twenty criteria produce a document people skim once during onboarding and never open again.

Five to eight lines for most teams. If your list is longer, check whether some items are really acceptance criteria for particular work types rather than universal standards.

Letting "done" mean different things per person

The definition only works if it is visible and referenced. Put it on the board, link it from the sprint, and read it during sprint review when confirming completion.

A definition of done that lives in a wiki page nobody opens has the same effect as no definition at all. The practical fix is to attach it to the workflow itself — a checklist on the task template, or a required step before a ticket can be closed — so meeting it is part of moving the work rather than a separate act of remembering.