Guide · Jira

Definition of Done vs acceptance criteria, with Jira examples

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

By Bartosz Stankiewicz, founder, Stanki Guild.

Teams mix these two up, and the cost is work in the wrong place: acceptance criteria written as a team-wide checklist, so nobody can tell whether one story is finished, or a Definition of Done pasted into every ticket as criteria, so the story never seems done.

The short version: acceptance criteria define this work item. The Definition of Done defines the team's quality bar for every work item. The Scrum Guide describes the Definition of Done as a formal description of the state of the Increment when it meets the quality measures required for the product; acceptance criteria are not a Scrum Guide term at all, but a common practice for describing what a single backlog item must do.

The table

	Acceptance criteria	Definition of Done
Scope	This one story, bug or task	Every work item the team finishes
Written by	Product owner with the team, per item	The whole team, once, revisited from time to time
Changes	With every item	Rarely, by team agreement
Answers	Does it do what was asked?	Did we build it the way we agreed to work?
Lives in Jira	The description or a dedicated field	A checklist on every work item, or a team agreement
Checked by	Product owner, QA, the demo	The team, ideally enforced at the transition to Done

One story, both lists

Story: "As a player, I can reset my password so I can get back into the game."

Acceptance criteria (for this story only):

I can request a reset from the login screen with my e-mail address.
I receive a link that works for 30 minutes and stops working after one use.
After resetting, I can log in with the new password and not with the old one.
If the e-mail address is unknown, the screen says "if that address exists, we sent a link" without confirming it.

Definition of Done (the same for every story):

Code reviewed by someone other than the author
Unit tests written and passing in CI
Acceptance criteria demonstrated on staging
No new errors in the smoke test
Documentation or runbook updated if behaviour changed
Security review done for anything touching authentication

None of the DoD items mention passwords. Swap the story for "export my order history" and the DoD stays the same while the criteria change completely. That is the test for which list an item belongs on.

Where each lives in Jira

Acceptance criteria: in the description, written before the sprint during refinement. The Given, When, Then format works well. Some teams use a dedicated paragraph field so the criteria are easy to find and to search.

Definition of Done, three common homes:

A Confluence page. Easy to write, easy to forget when dragging a card to Done.
A board agreement, for example a "Verified" column that the team only moves cards into when the DoD is met. Visible, but Jira does not enforce it.
A checklist on every work item, with the non-negotiable items marked as required and a workflow validator on the transition into Done. This is the only one of the three that Jira can enforce, and it needs a checklist app because native action items cannot be required or read by a validator. Our guide How to enforce a Definition of Done in Jira covers the options step by step.

If you use checklists, do not paste the DoD into each ticket by hand: apply a template automatically by issue type, so a checklist is never forgotten on creation. Mark only the truly non-negotiable items as required; when everything is required, people stop reading the list.

Can a story pass one and fail the other?

Yes, and both failures tell you something:

Passes the criteria, fails the DoD: it works, but it is unreviewed, untested or undocumented. It is a demo, not a finished increment, and it should not be Done.
Passes the DoD, fails the criteria: well engineered, but it does not do what was asked. Back to refinement.

A team that only enforces the DoD ships polished wrong things; a team that only checks criteria ships fragile right things. Check both, at different moments: criteria at review and demo, the DoD at the transition.

Two common confusions

Criteria disguised as DoD. "Works on staging" belongs in the DoD, but for one story the product owner needs "works on staging with 1,000 concurrent users". The load figure is a criterion of that story; the staging rule is DoD.
DoD items that do not apply. "Security review done" on every ticket, including a CSS fix, invites rubber-stamping. Either mark such items not applicable where they do not apply, or move them into a template for the work item types that need them. Review the DoD whenever it grows items that most work items skip.

How our app helps

Checklist Flow is our app. It puts a checklist on every Jira work item with items marked as Required, and the Checklist Definition of Done validator blocks the transition while a Required item is open. Items that do not apply can be marked N/A, which counts as satisfied and is recorded. With a paid licence, templates can be auto-applied by issue type, global checklists can cover many projects at once, and the DoD Health page lists the work items whose checklist is not met for a project, sprint or epic. JQL fields such as dodMet and checklistProgress work in every edition, and every change is recorded with who, what and when.

The template library includes free Definition of Done and Definition of Ready templates. Checklist Flow is free for up to 10 users with every feature, then from USD 0.80 per user per month for the first 100 users. See the documentation and the comparison with other checklist apps.

Common questions

Who owns the Definition of Done?

The Scrum Guide gives it to the Scrum Team: if the organisation has a standard Definition of Done, the team follows it as a minimum, otherwise the team creates one. Acceptance criteria for each item are usually written by the product owner together with the team.

How long should a Definition of Done be?

There is no standard length. Keep it to items that genuinely apply to almost every work item and that the team will actually check. If several teams share a DoD that keeps growing, split it into a shared core and per-team additions.

Should acceptance criteria also block the transition?

Usually not. The product owner accepts a story after the demo, which is a human judgement rather than a gate. Some teams add a required "Product owner accepted" checklist item; that works as long as it really is required.

What is a Definition of Ready, then?

The mirror image for intake: what a story needs before the team will plan it, such as clear acceptance criteria and an estimate. It is a checklist for refinement, not for the transition to Done.