Short definition
The Definition of Done (DoD) is a Scrum team's shared checklist of conditions an issue must satisfy before it can be moved to Done. Typical items include code merged, tests passing, documentation updated, release notes drafted, and product-owner acceptance. The DoD lives outside Jira - on a wiki page or sprint goal board - and is referenced during sprint review and backlog refinement.
What the Definition of Done is for
The DoD answers a recurring question: “this looks finished - can we ship it?” Without a shared answer, every story turns into a one-off negotiation between developer, QA, product owner, and ops. With a DoD, the answer is “go through the checklist; if everything’s ticked, yes.”
The list is short - usually six to twelve items - and applies uniformly across all stories of a given type. Examples for a backend story might include: unit tests written and passing, integration tests passing in CI, code reviewed by at least one peer, documentation updated for any public-API change, release notes entry drafted, observability (logs/metrics) added for new code paths, no new high-severity findings in static analysis.
DoD vs. acceptance criteria
These are commonly confused. Acceptance criteria describe what this specific story must do - the behavioural contract a particular feature satisfies. The DoD is the quality bar every story must clear regardless of its content. A story is done when both are true.
A useful mental model: acceptance criteria are the “what,” the DoD is the “how well.” A story can satisfy acceptance criteria with no tests, no docs, and no release notes - in which case it’s met the contract but violated the DoD, and isn’t done.
Operationalising the DoD in Jira
Three patterns, in order of how reliably they enforce the checklist:
- Wiki page everyone refers to. Weakest. Easy to ignore under deadline pressure.
- Workflow conditions on the Done transition. Stronger for objective checks (e.g. only allow Done when all sub-tasks are Done). Limited for subjective items.
- Standard sub-tasks under every story. Most reliable. Each DoD item becomes a sub-task that must be closed before the parent can close. The checklist is on the issue, visible at all times.
STM Issue Templates exists for pattern 3: define the DoD-as-sub-tasks once, attach it to an On Issue Created Executor on the Story issue type, and every new story arrives with the full DoD checklist auto-created and assigned to the right roles.
DoD evolves
The DoD is not a static document. Teams add items after incidents (“we shipped something with no rollback plan - add ‘rollback plan documented’ to the DoD”), and remove items that have become obsolete (superseded by automation). Sprint retrospective is the right place to propose changes; once changed, the team’s template / wiki / sub-task set is updated and the new DoD applies to subsequent stories.
See also (Redmoon products)
Common questions
What is the Definition of Done in Scrum?
The Definition of Done is a Scrum team's shared checklist of conditions an issue must satisfy before it can be moved to Done. Typical items include code merged, tests passing, documentation updated, release notes drafted, and product-owner acceptance. The DoD lives outside Jira - on a wiki page or sprint goal board - and is referenced during sprint review and backlog refinement.
How is Definition of Done different from acceptance criteria?
Acceptance criteria are per-story conditions describing what the story specifically must do ('user can log in with SSO'). The DoD is per-team and applies to every story uniformly - the quality bar that every deliverable must clear. A story is done when both its acceptance criteria are met and the team's DoD is satisfied.
Should the Definition of Done be enforced in Jira workflow?
Partially. Items that are objectively checkable (tests passing, code merged) are good candidates for workflow conditions or automation rules that gate the Done transition. Subjective items (PO acceptance, docs reviewed) are usually enforced by sub-task checklists, status columns, or team discipline rather than hard workflow blocks.
How do teams operationalise the DoD?
The most reliable pattern is encoding the DoD as sub-tasks on every story. STM Issue Templates auto-creates the standard sub-task set (QA, documentation, release notes, security review) on each new story, so the DoD checklist is visible on the issue itself rather than buried on a wiki page no one reads.