The Definition of Done (DoD) is the Scrum Team's formal description of the quality an increment must meet before it counts as done: reviewed, tested, integrated, documented, deployable, whatever your product requires. It applies to every backlog item, unlike acceptance criteria, which are specific to one story. In the 2020 Scrum Guide, the DoD is the commitment attached to the Increment: work that doesn't meet it can't be released or even presented at the Sprint Review, and it goes back to the Product Backlog.
This page gives you example DoDs for three very different teams, a comparison table of DoD, Definition of Ready and acceptance criteria, and the practical rules for keeping a DoD honest.
What the Scrum Guide actually says about the Definition of Done
The relevant points, paraphrased from the 2020 Scrum Guide:
- The DoD is a formal description of the state of the Increment when it meets the quality measures required for the product.
- The moment a Product Backlog item meets the DoD, an Increment is born.
- If an item doesn't meet the DoD, it can't be released or presented at the Sprint Review. It returns to the Product Backlog.
- If the organization has a standard DoD, all Scrum Teams follow it as a minimum. Otherwise, the Scrum Team creates one appropriate for the product.
- Multiple Scrum Teams working on the same product share one DoD.
There's no "done but not done-done" in that description. Either an item meets the DoD or it isn't done.
Definition of Done vs. Definition of Ready vs. acceptance criteria
These three get confused constantly. The quickest way to separate them:
| Definition of Ready | Acceptance criteria | Definition of Done | |
|---|---|---|---|
| Question it answers | Is this story clear enough to start? | Does this story do what was asked? | Does this work meet our quality bar? |
| Scope | Each backlog item, before the sprint | One specific story | Every item and the whole Increment |
| Who writes it | Whole team agrees the checklist; PO prepares stories | PO with the team, per story | Whole Scrum Team (or organization standard) |
| When it's checked | Refinement and sprint planning | During development and review | Before anything is called done |
| Changes how often | Occasionally, in retros | Every story is different | Rarely; tightened over time |
| In the Scrum Guide? | No (an optional team practice) | No (a common practice) | Yes, required |
| Example | "Acceptance criteria written, dependencies linked, team estimate" | "Given an expired link, when clicked, then show Resend" | "Code reviewed, tests pass in CI, deployed to staging, docs updated" |
A story is complete only when both its acceptance criteria and the DoD are satisfied. Acceptance criteria say what this feature does; the DoD says how well everything is built. For the entry side, see the Definition of Ready checklist.
A common mistake is putting story-specific items in the DoD ("export includes CSV headers") or universal items in every story's acceptance criteria ("code is reviewed"). If it applies to every item, it belongs in the DoD.
Definition of Done examples
These are starting points. Delete what doesn't apply and add what your last few incidents taught you.
Example 1: Web application team
## Definition of Done: Web app (v3)
Code
- [ ] Merged to main via pull request with at least one approving review
- [ ] Linting and type checks pass with no new warnings
- [ ] No TODOs left without a linked ticket
Tests
- [ ] Unit tests cover new logic; CI is green
- [ ] Acceptance criteria verified (automated where practical, otherwise
manually by someone who didn't write the code)
- [ ] Existing end-to-end suite passes
- [ ] Checked in latest Chrome, Safari and Firefox, and on one mobile viewport
Quality
- [ ] Keyboard navigation and screen reader labels work for new UI
(team target: WCAG 2.1 AA)
- [ ] Dependency vulnerability scan shows no new high/critical issues
- [ ] No personal data logged
Release
- [ ] Deployed to staging and smoke-tested
- [ ] Database migrations are reversible
- [ ] Behind a feature flag if not ready for all users
- [ ] Monitoring/alerting added for new endpoints or jobs
Docs
- [ ] User-facing help or changelog updated if behavior changed
- [ ] PO has seen it working
Example 2: Data / analytics team
Data teams often borrow software DoDs that don't fit. Their "done" is about correctness and trust in the numbers.
## Definition of Done: Data team (v2)
Pipeline / model
- [ ] Code in version control, reviewed by another analyst or engineer
- [ ] Runs end-to-end on production data in the scheduled job, not only in a notebook
- [ ] Idempotent: re-running for the same date doesn't duplicate rows
Data quality
- [ ] Tests for not-null, uniqueness and accepted values on key columns
- [ ] Row counts reconciled against the source system for one sample period
- [ ] Freshness check/alert configured
Outputs
- [ ] Metric definitions written in the data catalog/glossary
- [ ] Dashboard figures spot-checked against a manual query
- [ ] Access permissions set; no sensitive columns exposed to the wrong audience
Handoff
- [ ] Stakeholder who requested it has reviewed the output
- [ ] Owner and on-call path documented
Example 3: Non-software team (marketing content)
The DoD works for any team that produces something others rely on. See agile for non-software teams for more on adapting Scrum outside engineering.
## Definition of Done: Marketing content team (v1)
- [ ] Brief's goal and audience addressed (checked against the brief)
- [ ] Edited by a second person for clarity, tone and style guide
- [ ] Facts, numbers and claims verified with a source
- [ ] Legal/compliance review done if it mentions pricing, competitors or regulated claims
- [ ] Links, images and alt text checked; accessible color contrast
- [ ] SEO basics: title, meta description, one clear H1
- [ ] Scheduled or published in the CMS, with tracking parameters on links
- [ ] Asset files stored in the shared library with the agreed naming
The same idea applies to hardware, HR, legal or sales teams: list the checks that, if skipped, cause rework or embarrassment later. Engineering teams outside software can see agile in engineering and manufacturing.
How to create your Definition of Done
Run this as a 60-minute session with the whole Scrum Team.
- Silent brainstorm (10 min). Everyone writes what "done" should mean, prompted by: "Think of the last time something we called done came back to bite us."
- Cluster (10 min). Group the notes: code, testing, security, release, docs.
- Test each item (25 min). For every candidate ask: Can we do this every sprint with our current skills and tools? Would skipping it cause real problems? Can we automate it?
- Agree (10 min). Keep what everyone can commit to doing for every item. A short DoD that's always followed beats a long one that's routinely skipped.
- Publish (5 min). Put it where the work happens: the pull request template, the top of the board, the story template.
Make it cheap to follow
The most effective DoD items are the ones you don't have to remember. If "tests pass" and "lint clean" are enforced by CI, they can't be skipped. Put the rest in a PR template checklist. Items that rely purely on memory erode first.
Evolving the DoD
The Scrum Guide expects teams to raise their quality bar over time, so treat the DoD as something that tightens.
| Signal | What to do |
|---|---|
| The same type of bug escapes repeatedly | Add a specific check that would have caught it |
| An item is skipped every sprint | Either automate it, make the work smaller so there's time, or remove it honestly |
| A new constraint arrives (accessibility law, security audit) | Add it to the DoD, and expect velocity to dip while you adapt |
| Items are "done" but can't be released for weeks | The DoD stops short of releasable; move release steps inside it |
Review the DoD in a retrospective every few sprints: "Did anything we called done turn out not to be? Did anything in the DoD not earn its place?"
Common pitfalls
Vague items. "Tested" or "reviewed" mean different things to different people. Write "unit tests cover new logic and CI is green," "one approving review."
Too demanding for the team's real situation. A DoD that requires production deployment when the team has no deploy rights isn't achievable. Write what you control, and push to expand that control.
"Done-ish" exceptions. "We'll add tests next sprint" is how undone work piles up. If an item regularly can't meet the DoD, either the stories are too big or the DoD needs changing; quietly skipping it is the worst option.
Estimating without the DoD in mind. If testing, review and deployment are in the DoD, they're in the estimate. A story pointed as "just the coding" will overrun every time. This is also why DoD changes affect velocity; see calibrating story points.
Different DoDs on one product. Several teams on the same product must share one DoD, or their increments can't be integrated with confidence. See standardizing estimation across an enterprise for the related problem with points.
Where the DoD shows up in the sprint
| Event | How the DoD is used |
|---|---|
| Refinement and planning | Estimates include all DoD work; sprint planning forecasts based on it |
| Daily work | PR template and CI enforce it |
| Sprint Review | Only items meeting the DoD are shown |
| Retrospective | Review whether it held up, and what to tighten |
FAQ
What is the definition of done in Scrum?
It's the Scrum Team's shared, formal description of the quality an Increment must meet, such as reviewed code, passing tests, deployment to staging and updated docs. The 2020 Scrum Guide makes it the commitment for the Increment: anything that doesn't meet it can't be released or shown at the Sprint Review and returns to the Product Backlog.
What are some definition of done examples?
A web team's DoD typically includes peer code review, green CI, acceptance criteria verified, cross-browser and accessibility checks, a staging deploy and monitoring. A data team's might require reconciled row counts, data quality tests and documented metric definitions. A content team's might require a second-person edit, fact-checking and legal review where needed.
What is the difference between definition of done and acceptance criteria?
Acceptance criteria are specific to one story and describe what that feature must do. The Definition of Done applies to every item and describes the quality standard all work must meet. A story is complete only when both its acceptance criteria and the DoD are satisfied.
Who creates the definition of done?
If the organization has a standard DoD, every Scrum Team uses it as a minimum. Otherwise, the Scrum Team (developers, Product Owner and Scrum Master together) creates one suited to the product. Teams working on the same product share a single DoD.
Can the definition of done change during a sprint?
It's normally reviewed and updated in a retrospective and applied from the next sprint, so the team isn't changing the rules for work already in progress. If you add items, expect velocity to drop for a sprint or two while estimates catch up with the extra work.