Definition of Done Template for Jira [2026 Guide]
A practical DoD template with 10 criteria you can use in Jira today. Copy-paste ready, with examples for different team maturity levels.
A Definition of Done (DoD)is a checklist of conditions that must be true before a team can call an issue "complete". It is the team's contract with itself, and with stakeholders, about what "done" actually means.
Without an explicit DoD, "done" drifts. One developer means "code works on my branch". Another means "merged and tested in staging". The PO means "a user can use it in production". Three definitions, one Jira status, and a steady stream of reopened tickets a week later. For the input-side companion, see our Definition of Ready template for Jira.
The 10-criteria DoD template
This template covers what most software teams need. Every criterion maps to something verifiable in Jira (a field, a linked artefact, or a status), so you can check it manually or with automation.
| # | Criterion | Jira field or signal | Why it matters |
|---|---|---|---|
| 1 | Status is Done | Status (Done category) | Issue has transitioned through the full workflow, not just dragged across the board |
| 2 | Resolution is set | Resolution | Distinguishes "Done" from "Cancelled" or "Won't Do" for clean reporting |
| 3 | All subtasks are Done | Subtasks | A parent issue is not finished while children are still open |
| 4 | Acceptance criteria verified | Description (AC section) or custom field | The original ask is provably met, not just "feels done" |
| 5 | Code reviewed and merged | Development panel (linked PR) | At least one peer reviewed the change before it landed |
| 6 | Tests written and passing | Linked test issues or test-passed label | Behaviour is regression-protected, not just verified once manually |
| 7 | Documentation updated | Linked Confluence page or comment confirming update | The next person to touch this can pick it up without archaeology |
| 8 | Deployed to production | Fix Version released, or deploy label | The strictest reading of "done" is in the hands of users, not in staging |
| 9 | No blocking bugs linked | Issue Links ("blocks", "is blocked by") | Known defects are closed before declaring the work complete |
| 10 | Stakeholder sign-off | Comment from PO or QA, or approval label | The person who asked for the work confirms it meets intent |
Adapting the template for your team
Ten criteria is the upper end. Most teams need a tighter list. Here is a quick guide by team maturity and context:
Starter (new Scrum or Kanban team)
Pick 4 criteria that catch the most common failures: status is Done, all subtasks done, code reviewed, tests passing. Add more once these four become reflex.
Growing (established release cadence)
Add acceptance criteria verified, documentation updated, and resolution set. At this stage you start needing reporting that distinguishes finished work from abandoned work, which depends on Resolution being filled.
Mature (multi-team, regulated, or customer-facing)
Use all 10 criteria plus domain-specific ones. Common additions: "security scan passed", "a11y checked", "release notes drafted", "feature flag configured", "telemetry instrumented".
DoD vs Acceptance Criteria — not the same
A common mistake is conflating these. The Definition of Done applies to everyissue of a given type, every sprint, forever. It is the team's baseline of quality.
Acceptance Criteria are specific to onestory. They describe the unique behaviour that story delivers ("when a user clicks Submit, an email is sent within 5 seconds"). They change with every story.
DoD says "tests must pass". AC says "the test that the email is sent within 5 seconds must pass". You need both.
How to implement DoD in Jira
There are three approaches, from manual to fully automated:
Option 1: Manual checklist in description
Add a DoD checklist template to your issue description (or use a marketplace checklist app). Team members tick boxes as they go. Simple, but two failure modes: people forget to tick, and people tick boxes for things they did not actually do.
Option 2: Workflow validators
Use ScriptRunner or JMWE to block the transition to Done unless specific conditions are met (subtasks closed, resolution set, PR linked). Powerful, but admin-heavy and brittle when criteria change.
Option 3: Dedicated DoD app (recommended)
Tools like ReDoevaluate all criteria automatically against actual Jira fields and show a real-time 0–100% completeness score on the issue. The score updates on every change — no manual ticking, no validators to maintain. Custom formula-based criteria let you encode rules like "all subtasks Done AND Fix Version is released AND no open bugs link to this issue" without scripting. We unpacked why this model outperforms manual checklists in auto vs manual Definition of Done.
Common mistakes to avoid
- Treating DoD as a Confluence page nobody reads. If the criteria are not visible at the moment of marking Done, they will not be checked. Embed them in the workflow.
- Different DoD per developer.The whole team must agree. One person's "done" ends at merge, another's ends at deploy. Pick one and document it.
- No Resolution field. Issues marked Done with empty Resolution wreck velocity reporting and Done-by-version queries. Force Resolution on every Done transition.
- Conflating Done with Released.If your team marks tickets Done at merge but they sit in staging for two weeks, your burndown lies. Either rename the column or move "deployed" into the DoD.
- Never reviewing the DoD. Revisit every quarter. Drop criteria that no longer add value, add criteria for recurring failure patterns.
Key takeaway
A Definition of Done template is most valuable when it is enforced objectively, not socially. The strongest implementations evaluate the criteria against actual Jira state on every change, so "is this done?" has a quantitative answer the whole team can see. Start with 4 criteria, embed them where work happens, and add more as the team's capacity to handle them grows.