# Definition of Done: [Team or product]

> A Definition of Done (DoD) is the shared, written quality bar that a piece of work must clear before the team calls
> it part of a usable Increment. This template follows the Scrum Guide 2020 (Schwaber and Sutherland, the current
> revision as of October 2026): an item counts as part of an Increment only once it meets the DoD; anything short of
> that is neither released nor shown at the Sprint Review, and goes back to the Product Backlog. Where the
> organisation sets its own DoD standard, each team treats it as the floor. The optional Definition of Ready and the quality gates are
> common practice, not part of Scrum. Replace every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Start from the organisational standard if one exists (section 1), then add team criteria (section 2). A team can
  make its DoD stricter than the organisation's, never weaker.
- Every criterion must be checkable by someone who did not do the work. "Code is good" is not a criterion;
  "reviewed and approved by at least one other Developer" is.
- Keep the DoD visible (pinned in the team space and linked from every backlog item).
- Change the DoD in the Sprint Retrospective and record the change (section 6). Tightening it often reveals undone
  work in earlier Increments; plan for that.
- The worked example is the fictional Tallow Notes web team, the same team as product/product-backlog.
-->

## Document control

| Field | Value |
|---|---|
| Document ID | [DOD-TEAM-NN] |
| Team(s) using this DoD | [Team names] |
| Product | [Product name] |
| Organisational standard applied | [Link or "none"] |
| Version | [1.0] |
| Owner | [Scrum Team, with Scrum Master as facilitator] |
| Last updated | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 | YYYY-MM-DD | [@scrum-master] | Agreed by the Scrum Team |
| [1.1] | YYYY-MM-DD | [@scrum-master] | [Change agreed in Retrospective, Sprint NN] |

## 1. Organisational minimum

<!-- Guidance: Copy or link the criteria every team in the organisation must meet. If multiple teams work on one product, they share one DoD. If there is no organisational standard, write "None" and go to section 2. -->

| ID | Criterion | Source |
|---|---|---|
| ORG-01 | [Criterion] | [Policy or standard] |
| ORG-01 *(Example)* | No known critical or high security finding open in the change | Secure development policy |
| ORG-02 *(Example)* | Personal data handling matches the record of processing; new data fields reviewed by privacy contact | Privacy policy |
| ORG-03 *(Example)* | User-facing changes meet WCAG 2.2 level AA for the affected screens | Accessibility policy |

## 2. Team Definition of Done

<!-- Guidance: List the criteria every Product Backlog item must meet before it counts as done. Group them so the list can be scanned. Ten to twenty criteria is typical; more usually means some should be automated in the pipeline. Mark which criteria are checked automatically. -->

| ID | Area | Criterion | How it is checked | Automated |
|---|---|---|---|---|
| DOD-01 | [Area] | [Criterion] | [Evidence] | [Yes / No] |
| DOD-01 *(Example)* | Acceptance | All acceptance criteria of the item are met and accepted by the Product Owner | PO acceptance on the item | No |
| DOD-02 *(Example)* | Code | Reviewed and approved by at least one other Developer | Pull request approval | Yes |
| DOD-03 *(Example)* | Code | Lint and type checks pass with no new warnings | CI job | Yes |
| DOD-04 *(Example)* | Tests | Unit tests added or updated; all tests pass | CI job | Yes |
| DOD-05 *(Example)* | Tests | End-to-end test covers the main user path of the item | CI job | Yes |
| DOD-06 *(Example)* | Quality | No new defects of severity 1 or 2 open against the item | Issue tracker query | No |
| DOD-07 *(Example)* | Accessibility | Keyboard-only and screen reader check on changed screens | Checklist in pull request (design/accessibility-checklist) | Partly |
| DOD-08 *(Example)* | Security | Dependency and static analysis scans show no new high findings | CI job | Yes |
| DOD-09 *(Example)* | Performance | Page load of changed screens within budget (p75 under 2.5 s on test device) | Performance job | Yes |
| DOD-10 *(Example)* | Release | Merged to main and deployed to the production environment behind a feature flag or released | Deployment log | Yes |
| DOD-11 *(Example)* | Observability | Events and error logging added for new flows; dashboards updated | Pull request checklist | No |
| DOD-12 *(Example)* | Documentation | Help article or release note drafted for user-visible changes | Link on the item | No |
| DOD-13 *(Example)* | Localisation | New UI strings added to all supported languages or flagged for translation | Missing-string check | Yes |

## 3. Quality gates beyond a single item

<!-- Guidance: Some quality checks apply to the Increment or a release rather than to each item (for example a regression run or a penetration test). List them separately with when they run, so they are not forgotten and do not slow every item. -->

| Gate ID | Gate | Applies to | When | Owner |
|---|---|---|---|---|
| QG-01 | [Gate] | [Increment / release] | [Timing] | [@owner] |
| QG-01 *(Example)* | Full regression suite on all supported browsers | Each release | Before production rollout beyond 10% | QA lead |
| QG-02 *(Example)* | Privacy review of any new data flow | Release containing the change | Before release | Privacy contact |
| QG-03 *(Example)* | External penetration test | Major release | Yearly or before a major release | Security lead |

## 4. Definition of Ready (optional)

<!-- Guidance: A Definition of Ready is not in the Scrum Guide. If the team uses one, keep it light so it helps conversation rather than blocking work. Keep the same list in product/product-backlog to avoid two versions. -->

- [ ] Linked to the Product Goal or marked as maintenance.
- [ ] Acceptance criteria written and understood by the Developers.
- [ ] Sized and small enough to finish within one Sprint.
- [ ] Dependencies known and none blocking the start.
- [ ] Designs or examples available where the item changes the user interface.

## 5. When an item is not done

<!-- Guidance: Agree up front what happens at the end of the Sprint to unfinished work, so it is not argued case by case. -->

- An item that does not meet every criterion is not done. It is not shown as done at the Sprint Review and is not
  released.
- It returns to the Product Backlog, where the Product Owner reorders it. Partial credit (for example "80% done") is
  not counted toward velocity or forecasts.
- If the team repeatedly cannot meet a criterion, raise it in the Retrospective rather than quietly skipping it.

## 6. DoD change log

<!-- Guidance: Record every change, its reason and its effect on earlier Increments, so the team can see the DoD maturing over time. -->

| Date | Change | Reason | Effect on earlier work | Agreed in |
|---|---|---|---|---|
| YYYY-MM-DD | [Change] | [Reason] | [Undone work added to backlog?] | [Retro Sprint NN] |
| *Example:* 2026-10-23 | Added DOD-13 (localisation) | Two releases shipped with untranslated strings | Backlog item PBI-109 added to fix older screens | Retro Sprint 31 |

## Related templates and references

- product/product-backlog, product/sprint-planning, product/sprint-retro, product/user-story
- dev/pull-request, dev/test-plan, dev/release-checklist, dev/coding-standards, design/accessibility-checklist
- Schwaber, K. and Sutherland, J. (2020). *The Scrum Guide*, section "Commitment: Definition of Done":
  https://scrumguides.org/scrum-guide.html
- W3C, Web Content Accessibility Guidelines (WCAG) 2.2: https://www.w3.org/TR/WCAG22/

## Standard and licence note

Structure aligned with the Definition of Done described in the Scrum Guide 2020, which is published under
CC BY-SA 4.0. This template cites the Guide by name and does not copy its text; all wording and the example criteria
are original. The Definition of Ready and quality gates are common practice, not part of Scrum. Check the current
Scrum Guide at scrumguides.org. Template licence: MIT.