Guide · Jira

How to enforce a Definition of Done in Jira

Checklist Flow for Jira 3.1.1 is the production version (1 November 2026). Last updated 1 November 2026. On the Atlassian Marketplace.

By Bartosz Stankiewicz, founder, Stanki Guild.

To add a Definition of Done in Jira Cloud without an app, create a Checkboxes custom field with one option per DoD item, add it to the project's screens, and add the built-in Field Required validator for it on the transition into Done. Jira has no checklist field type (JRACLOUD-94964), so this is the closest native setup, and it has a limit: the validator checks only that the field has a value, not that every box is ticked. The exact steps are under Way 1; the native alternatives and a Marketplace app that checks every item follow.

This guide is about the Definition of Done in Jira Cloud: how to make it a gate that stops a work item, not a page nobody opens. A Definition of Done (DoD) is the shared list of conditions every work item must meet before the team calls it finished: code reviewed, tests written, documentation updated, security check passed. The Scrum Guide describes it as a formal description of the state of the Increment when it meets the quality measures required for the product. A work item that fails the DoD is not done, whatever its status says.

Writing the DoD is rarely the problem. Enforcing it is: in a default Jira workflow, anyone who can transition a work item can move it to Done, and afterwards nobody can show which DoD items were checked, or by whom. This guide walks through the options in Jira Cloud, native ones first, with what each one actually enforces.

The short answer: a Definition of Done is enforced only when a workflow validator refuses the transition into Done. Native action items cannot do that, a required-field validator checks only that a field has a value, and a board column relies on trust. To check every item you need a checklist app with its own validator (Checklist Flow is ours), tested on a sandbox work item first.

First, the native baseline: action items

Jira Cloud has native action items: type [] in the description and you get a checkbox. Atlassian closed the long-standing request for checklists in text fields as fixed when they shipped (JRACLOUD-47605; announcement).

Action items are good for personal to-dos. They cannot enforce a DoD:

They cannot be marked as required, and nothing stops a transition while one is open.
The built-in workflow validators do not read them.
Jira Automation cannot read or tick them; the request is open as JRACLOUD-96783.
There is no checklist field type either (JRACLOUD-94964).

If your DoD is a reminder, action items may be enough. If it is a control, read on.

Way 1: a DoD custom field with a required-field validator

Steps, in a company-managed project (you need Jira administrator rights):

In Jira's administration settings, create a custom field. A Checkboxes field with one option per DoD item works best; a Paragraph field works for free text.
Add the field to the screens the project uses.
In the workflow, open the transition into Done and add the built-in Field Required validator for that field.

What it gives you: the DoD sits on the work item, and the transition fails while the field is empty. What it does not give you: a check that every item is ticked. The validator only checks that the field has a value, so ticking one box out of six passes. Anyone who can edit the work item can tick the boxes, and the work item history shows the field change, not a per-item record.

Way 2: a board column with exit criteria

Steps:

Open the board settings, Columns.
Keep a separate "Verified" or "Accepted" column after the working columns.
Write the DoD down as the team's working agreement for moving a card into that column.

This creates a visible speed bump: work parked before "Verified" with the DoD unmet is easy to spot in a stand-up. It is still trust-based, because Jira does not stop the drag. Use it together with way 1 or way 3, not instead of them.

Way 3: a checklist app with a workflow validator

The only native mechanism that refuses a transition is a workflow validator, and the built-in validators cannot count checklist items. Marketplace checklist apps fill that gap by shipping their own validator. The pattern is the same whichever app you choose:

Install a checklist app that provides a workflow validator.
Add the DoD items to a work item (or, better, to a template) and mark the items that must not be skipped as required.
In the workflow editor, open the transition into Done and add the app's validator.
Publish the workflow and test it: try to move a work item with an open required item to Done. The transition should be refused with a message.

Questions to ask any app before you rely on it:

What happens when the validator itself cannot complete its check? A validator that lets the transition through on an error is a control that disappears during an outage. Ask whether it fails closed.
Does it work with your project type? Forge app validators work in company-managed projects by default and in team-managed projects only when the app opts in.
Can you see DoD status across many work items, through JQL fields or a report, so you catch drift before the sprint review rather than after?
Is there a record of who checked each item and when, and can an administrator clear it?

Definition of Done apps for Jira: what to look for

If you searched the Marketplace for a Definition of Done app for Jira, these are the points that decide whether an app enforces anything or only displays a list:

A workflow validator. The built-in validators cannot read checklist items (see the baseline above), so enforcement needs an app that ships its own validator.
Required items. A DoD has items that must not be skipped and items that are advice. Look for a way to mark the first kind.
Failing closed. Ask what the validator does when its own check cannot complete.
Your project type. Forge app validators work in company-managed projects by default and in team-managed projects only when the app opts in.
Templates. One DoD applied to many work items, ideally by work type, so a work item with no checklist is not simply waved through.
A search for drift. Checklist state in JQL or a report, so you find work that slipped through before the sprint review.
A record. Who checked each item and when, and whether anyone can clear it.
The price at your size. The table shows the annual list price at 10, 50 and 100 users.

Checklist apps in our tracked list, as read from the Marketplace data:

App	Installs	Reviews	10 users	50 users	100 users
Checklists Free (HeroCoders)	30,194	1,026	no price data	no price data	no price data
Checklists Pro (HeroCoders)	7,782	278	$0	$410	$820
Smart Checklists Free	4,927	84	no price data	no price data	no price data
Smart Checklists for Jira	4,643	151	$0	$450	$900
Checklists Enterprise (HeroCoders)	4,547	149	$50	$500	$1,000
Checklist Flow (ours)	not shown	none yet	$0	$400	$800

Read from the Atlassian Marketplace data on 31 October 2026. Prices are the annual list price in USD for the first year at 10, 50 and 100 users. The rows are the 5 most-installed of the 7 checklist apps for Jira in our tracked list, ordered by installs; this is not the order of the Marketplace search results, and apps outside our list are not shown. A blank install figure means the data held none. Star ratings are left out on purpose: the star field in the Marketplace data does not always match the rating shown on the listing, so open the listing for the current rating.

The Marketplace data does not say which of these apps has a workflow validator or how it behaves on an error, so check each listing against the points above before you install. Checklist Flow is ours and is the last row.

If your DoD runs on Smart Checklist Free, note that its vendor ends support on 15 December 2026: see Smart Checklist Free end of support.

Finding work items that already slipped through

Whatever option you pick, keep a saved filter for "done but not really". With a checklist app that writes its state to JQL fields this is one query. With Checklist Flow, for example: dodMet = "false" AND statusCategory = Done. With way 1, you can at least find done work items where the field is empty ("Definition of Done" is EMPTY AND statusCategory = Done, using your field name), but not those where only some boxes were ticked.

How our app helps

Checklist Flow is our app, so weigh this section accordingly. It puts a checklist panel on every Jira work item. You mark items as Required, and the Checklist Definition of Done validator blocks the transition while a Required item is open; if the check cannot be completed, the transition stays blocked. Two limits to know: a work item with no checklist is never blocked, so pair the validator with templates applied by issue type (a paid feature), and the validator message names at most three open items and gives the number of the rest.

Every change is recorded with who, what and when in an append-only history that no role can clear in the app, chained with SHA-256 hashes and exportable as CSV or JSON. The template library has 49 templates in 18 categories, including a Definition of Done template with the required items already marked.

Checklist Flow is free for up to 10 users, with every feature. Above that the list price starts at USD 0.80 per user per month for the first 100 users, with lower rates in larger tiers. Without an active paid licence the app keeps working with a reduced set: the same 2,000 items per work item as with a licence, 10 saved templates, the validator, the JQL fields and the full history and export. See the Checklist Flow documentation and how it compares with other checklist apps.

Common questions

How do I add a Definition of Done in Jira?

Natively, in a company-managed project: as a Jira administrator, create a Checkboxes custom field with one option per DoD item, add it to the screens the project uses, and add the built-in Field Required validator for it on the transition into Done. Jira has no checklist field type, and the validator only checks that the field has a value, so ticking one box out of six passes. For a per-item gate, use a checklist app with its own workflow validator; Checklist Flow, which we make, is one. Native action items (type [] in the description) give checkboxes but enforce nothing.

Can Jira block a transition until a Definition of Done is met, without an app?

Only partly. The built-in Field Required validator can block the transition until a DoD field has a value, but it cannot check that every item in a checklist is done, and it cannot read native action items. A real per-item gate needs a checklist app with its own validator, or a scripted validator that you maintain.

Which Jira apps can enforce a Definition of Done?

Any checklist app that ships a workflow validator can. The table above lists the five most-installed checklist apps in our tracked list with their annual list prices, but the Marketplace data does not say which of them have a validator, so check each listing. Checklist Flow, which we make, has one: the Checklist Definition of Done validator.

Is the Definition of Done the same as acceptance criteria?

No. Acceptance criteria belong to one work item and describe its behaviour; the Definition of Done is shared by the team and describes the quality bar for every work item. See Definition of Done vs acceptance criteria for a worked example.

What happens if a checklist validator itself fails?

That depends on the app. Checklist Flow fails closed: if the check cannot be completed, the transition is blocked and the user is asked to try again. Ask this question about any validator you deploy.

Who can clear the checklist history?

In Checklist Flow, no role can clear or edit the history from inside the app, Jira administrators included. The one exception is personal data erasure, which replaces a person's account ID and records that it did so. Uninstalling the app deletes its data, history included, so export what you need to keep.