# Jira Definition of Done: Template + How to Enforce It

October 17, 2026 ·

<!-- -->

6 min read

[NGPilot](https://ngpilot.com)

Every team says it has a definition of done. Then you look at a closed ticket: the release notes were never written, one test is skipped, the customer was never told. Jira didn't fail them — Jira never knew what "done" meant. The Done button closes anything. This post gives you a copy-paste definition of done template for stories and bugs, shows where to store it so it's actually on every ticket, and walks through the enforcement options from free to fully gated.

**Quick answer:** A definition of done (DoD) is the team-wide checklist every issue satisfies before closing — distinct from per-story acceptance criteria. Jira has no native DoD field, so the setup that works is: keep the DoD as a checklist template applied to every new issue, flag the non-negotiables as **required**, and add a workflow validator ([Checklist Workflow Automation for Jira](https://marketplace.atlassian.com/apps/1795968238/), free up to 10 users) that blocks the Done transition while any required item is unfinished. Below: the template, the storage options, and the enforcement ladder.

## The Template[​](#the-template "Direct link to The Template")

### Definition of Done — user story[​](#definition-of-done--user-story "Direct link to Definition of Done — user story")

```
Code peer-reviewed

Unit + integration tests pass in CI

Acceptance criteria demonstrated to the reporter

No new high/critical vulnerabilities

Documentation and release notes updated

Feature flag / rollout plan confirmed

Stakeholders notified
```

Mark the first two and the release-notes line **required** — they are the ones teams skip under deadline pressure, and the ones that cost the most when skipped. The rest stay optional: nothing destroys a definition of done faster than twenty mandatory checkboxes nobody reads.

### Definition of Done — bug fix[​](#definition-of-done--bug-fix "Direct link to Definition of Done — bug fix")

```
Root cause identified (not just the symptom)

Fix verified in a production-like environment

Regression test added

Release notes / affected users updated

Related issues linked
```

Bugs need a different gate than stories — a defect closed without a regression test is a defect scheduled to return. Same project, second template, so "done" stays one auditable concept with two shapes.

### What the template is not[​](#what-the-template-is-not "Direct link to What the template is not")

Not a checklist of *who does what* (that's assignment) and not a list of *what this story must do* (that's acceptance criteria — keep those in the story's own description). The DoD is only the conditions that are true for **every** piece of finished work. If you're writing an item that applies to some tickets only, it belongs in acceptance criteria.

## Where to Store It (So People Actually See It)[​](#where-to-store-it-so-people-actually-see-it "Direct link to Where to Store It (So People Actually See It)")

| Option                              | What you get                                | What breaks                                       |
| ----------------------------------- | ------------------------------------------- | ------------------------------------------------- |
| Wiki page                           | One canonical copy                          | Nobody opens it; zero per-ticket visibility       |
| Description template                | On every ticket from birth                  | Free text — items get deleted, JQL can't see them |
| **Checklist template on the issue** | On every ticket, structured, JQL-searchable | Needs an app to render and enforce                |

The wiki page is where definitions of done go to die. The description template is one step better — [Modern Issue Templates for Jira](/apps/modern-issue-templates-for-jira.md) pre-loads a rich-text body (description, DoD section, testing notes) on every new issue automatically, so the checklist is at least *present* on birth. But presence is not enforcement: a text checklist in the description can be deleted by anyone, and nothing stops the transition.

## The Enforcement Ladder[​](#the-enforcement-ladder "Direct link to The Enforcement Ladder")

**Level 0 — nothing.** The default. Close the ticket, hope for the best.

**Level 1 — present.** The DoD template auto-applies to every new issue (issue template). Reviewers see it; nothing enforces it.

**Level 2 — enforced.** The checklist lives on the issue, the non-negotiables are **required**, and a validator blocks Done until they're done.

Level 2 is the whole point, and it needs one workflow edit with [Checklist Workflow Automation for Jira](https://marketplace.atlassian.com/apps/1795968238/):

1. A Jira admin opens **Project settings → Workflows**, edits the workflow, and on the transition into Done adds the validator **Checklist required items complete** (category: *Forge apps*).

2. From then on, closing an issue with an unfinished required item is refused, and Jira names the offenders:

   `Complete required checklist items before transitioning: "Code peer-reviewed", …`

3. Optional: add the **Complete required checklist items** post function to the same transition if your DoD documents *review steps* rather than work — it completes the required items automatically once the reviewer decides to move on.

Two rules make the gate predictable: only **exactly Done** satisfies a requirement (a custom status like *Waiting on vendor* still blocks, *Skipped* never counts), and the validator **fails open** — if the app can't read a checklist, the transition goes through rather than bricking the workflow.

## Audit What Slips Through[​](#audit-what-slips-through "Direct link to Audit What Slips Through")

Enforcement prevents new shortcuts; the JQL layer catches everything already in flight:

```
issue in hasIncompleteRequired()

cwaIncompleteRequired > 0 AND sprint in openSprints()

cwaOverdueRequired > 0
```

Save the first as a filter called "Owed before Done" and pin it as a dashboard gadget — it's the team's honest backlog of unfinished endings. Pair it with overdue reminders, which comment on issues where a required item has blown past its due date and mention the assignee (at most once every 7 days per issue, so it nudges without nagging).

## Do You Need an App for This?[​](#do-you-need-an-app-for-this "Direct link to Do You Need an App for This?")

For Level 1 — no. Any issue-template mechanism puts the DoD text on tickets.

For Level 2 — yes, something has to count checklist state inside a workflow validator, and native Jira can't. The honest landscape: [ScriptRunner](https://marketplace.atlassian.com/search?query=scriptrunner) can script the same gate if you already pay for it; HeroCoders' checklist app covers this ground; Checklist Workflow Automation does it without scripts and stays free up to 10 users, with the JQL functions, CSV round-trip and reminders built around the same required-item concept. Pick by what you need *around* the gate, not the gate itself — every option blocks the transition.

## Related Resources[​](#related-resources "Direct link to Related Resources")

* [How to Add a Checklist to Jira](/blog/jira-checklist.md) — the checklist mechanics in depth: panels, required flags, JQL and templates
* [Create Jira Issue Templates](/blog/how-to-create-jira-issue-templates.md) — put the DoD body on every ticket from birth
* [Plan Jira Sprints That Actually Work](/blog/plan-jira-sprints-that-actually-work.md) — where the DoD gate sits in sprint planning
* [Checklist Workflow Automation for Jira](/apps/checklist-workflow-automation-for-jira.md) — full documentation: enforcement, templates, CSV, JQL, audit log

## Sources[​](#sources "Direct link to Sources")

* [Manage workflow transitions — Atlassian Support](https://support.atlassian.com/jira-cloud-administration/docs/manage-workflow-transitions/) — validators and conditions on transitions
* [Jira workflow conditions — what native conditions can and can't check](https://support.atlassian.com/jira-cloud-administration/docs/configure-advanced-conditioning-in-workflows/) — the boundary that makes checklist validators necessary

Try <!-- -->Modern Issue Templates for Jira

Create issues from reusable templates with variables, GitHub import, and auto-apply — free for up to 10 users.

[Get it on the Atlassian Marketplace](https://marketplace.atlassian.com/apps/2564635381/modern-issue-templates-for-jira?utm_source=ngpilot.com\&utm_medium=website\&utm_campaign=modern-issue-templates-for-jira)

## Related guides

* [How to Add a Checklist to Jira — and Block Transitions Until Done](/blog/jira-checklist.md)
* [Create Jira Issue Templates — Import from GitHub, Markdown & Rich Text](/blog/how-to-create-jira-issue-templates.md)
* [Plan Jira Sprints That Actually Work](/blog/plan-jira-sprints-that-actually-work.md)

Explore NGPILOT[Browse Solutions](/solutions.md)[All Apps](/apps.md)[All Posts](/blog/archive.md)[Atlassian Marketplace →](https://marketplace.atlassian.com/vendors/1226848/?utm_source=ngpilot.com\&utm_medium=blog\&utm_campaign=hub-links)

**Tags:**

* [jira](/blog/tags/jira.md)
* [definition-of-done](/blog/tags/definition-of-done.md)
* [checklist](/blog/tags/checklist.md)
* [workflow](/blog/tags/workflow.md)
* [how-to](/blog/tags/how-to.md)
* [process](/blog/tags/process.md)
