Definition of Done vs. Acceptance Criteria: Why Your "Done" Tickets Keep Bouncing Back
Conflating these two checklists is why finished-looking tickets keep reopening. Here's the difference, and how to build a DoD your team will actually use.
10 min read
A ticket gets marked "Done" on Thursday. Friday morning, the product owner opens it, tries the flow, and finds the error state was never handled. The engineer swears it's done — the acceptance criteria said "user can reset their password," and they can. Nobody mentioned what happens when the reset link expires, or that error messages need to match the design system, or that it needs a test. Now it's Friday afternoon, the sprint review is in an hour, and the ticket bounces back to "In Progress" for the third time this month.
This is what happens when a team conflates two different questions: definition of done vs acceptance criteria. They sound similar enough that most teams never separate them, and that's exactly why "done" keeps meaning something different depending on who you ask. One defines whether a specific story delivers what was promised. The other defines whether any piece of work is actually ready to ship. Mix them up, and you get exactly the ticket above — technically correct, functionally unfinished.
This isn't just an agile ceremony nitpick. Standish Group's CHAOS Report data puts unclear or changing requirements as the leading factor in challenged and failed projects, cited in 24% of responses. A fuzzy definition of "done" is one of the most common ways that unclear requirements sneak into a sprint that otherwise looked perfectly planned.
- What Definition of Done and Acceptance Criteria actually mean
- Why teams conflate them in the first place
- The real cost of blurring the line
- How DoD and AC work together on a single story
- Building a Definition of Done your team will actually use
- A diagnostic checklist for your next sprint
What Definition of Done and Acceptance Criteria actually mean
Acceptance criteria are story-specific. They describe the conditions a single piece of work must satisfy to deliver the value it promised — written before development starts, usually by a product owner, and checked against that one story alone. "User receives a password reset email within one minute" is acceptance criteria. It says nothing about testing standards or code review.
Definition of done is universal. It's the quality bar the whole team applies to every story regardless of what that story does — code reviewed, tests passing, documentation updated, deployed to staging. Agile coach Mike Cohn, who has argued for decades that teams should stop treating these as interchangeable, describes conditions of satisfaction (his preferred term for acceptance criteria) as "specific to a given product backlog item," while the definition of done is "an agreed-upon set of things that must be true before any product backlog item is considered complete."
Put another way: acceptance criteria answer "does this feature do what it's supposed to?" Definition of done answers "is this feature ready to release?" A story can pass every acceptance criterion and still fail the definition of done — which is exactly what happened with the password reset ticket above.
Why teams conflate them in the first place
Most teams don't consciously decide to merge these two concepts. It happens gradually, for three predictable reasons:
- Nobody owns the DoD. Acceptance criteria get written every sprint because someone has to write the ticket. Definition of done gets written once, in a kickoff meeting eighteen months ago, and then never looked at again.
- Tickets only have one checkbox. Most issue trackers give you a single "Acceptance Criteria" field and a single "Done" column. If your tooling doesn't separate the two, your team's mental model won't either.
- "Done" becomes whatever gets the ticket moved. Under sprint-end pressure, people start treating acceptance criteria as the entire bar, because it's the more visible, easier-to-check list. The DoD — the quieter, less exciting stuff like error handling and documentation — quietly erodes.
This third one connects to a problem we wrote about recently in the context of AI coding agents: when "done" becomes a proxy metric instead of a verified outcome, the proxy gets gamed — sometimes by an AI model exploiting a benchmark, sometimes by a tired engineer at 4:45pm on a Friday. The mechanism is the same. If your definition of done isn't explicit, someone will quietly narrow it under deadline pressure, and nobody will notice until QA — or a customer — does.
The real cost of blurring the line
When DoD and AC collapse into one fuzzy bar, three things happen, usually in this order.
Rework climbs. Work that "passes" acceptance criteria but skips DoD steps like testing or documentation gets flagged in QA or, worse, in production — and has to be reopened. That rework doesn't just cost the original story; it competes with next sprint's committed work for the same engineering hours.
Sprint velocity gets unreliable. A story counted as done in sprint N that bounces back in sprint N+1 doesn't just cost the rework hours — it corrupts your velocity data for both sprints, making planning worse for everyone downstream. Related reading: our piece on why scope creep is a decision problem, not a people problem covers the same root cause from a different angle — unclear authority over what counts as "in."
Trust erodes. Once a product owner has been burned twice by "done" tickets that weren't, they stop trusting the board and start re-verifying everything manually — which defeats the entire point of having a shared definition of done. It's the same failure mode we described in our piece on retrospective action items that never get implemented: a shared standard that exists on paper but isn't actually enforced is worse than no standard, because it creates false confidence.
A definition of done that lives in someone's memory isn't a definition of done. It's a guess that changes depending on who's tired that week.
Here's the split most teams should be checking against:
| Symptom | Usually caused by | Fix belongs in |
|---|---|---|
| Feature works but error states crash or look broken | Missing edge-case handling in DoD | Definition of Done |
| Feature is technically solid but doesn't solve the user's problem | Acceptance criteria too vague or missing a scenario | Acceptance Criteria |
| Ticket reopened for missing tests or docs | DoD not enforced at review | Definition of Done |
| Product owner rejects a "complete" story in demo | AC didn't capture what "value delivered" actually meant | Acceptance Criteria |
How DoD and AC work together on a single story
Take a real example: a "Save for Later" feature on an e-commerce checkout page.
Acceptance criteria, written by the product owner for this story only, might include: items saved persist across sessions, a saved item shows a timestamp, and a user can move a saved item back to cart in one click.
Definition of done, applied to this story the same way it's applied to every other story on the board, might include: code peer-reviewed, unit tests written and passing, no new accessibility violations, feature flag configured, and documentation updated.
A story isn't finished until both lists are satisfied — not one or the other. This structure has staying power for a reason beyond tidiness: practitioner research on agile team performance consistently finds that teams with a clear, actively-used DoD outperform teams that don't have one, or that inherited one from another team without buy-in.
That buy-in detail matters more than most teams assume. A definition of done handed down by a PMO or copied from another team's wiki page rarely sticks — the team that didn't write it doesn't enforce it. The DoD that survives contact with a deadline is the one the team built themselves.
Building a Definition of Done your team will actually use
Most definition-of-done documents fail not because they're wrong, but because they're either too vague to check ("code is high quality") or too long to remember (a 40-item checklist nobody reads past item six). A DoD that survives sprint-end pressure needs three properties:
- Binary, not subjective. "Peer reviewed" is checkable. "Well-architected" is not.
- Short enough to hold in your head. Six to ten items, not thirty. If it's longer, split it into a core DoD plus feature-type-specific add-ons (e.g., "API endpoints also require updated Postman docs").
- Owned by the team that has to hit it. Written and revised by the engineers and QA who apply it every sprint, not inherited from a template.
A workable starting DoD for most software teams looks like this:
- Code peer-reviewed and approved
- Automated tests written and passing
- No new linter or type errors introduced
- Acceptance criteria for the story verified against the actual build, not just the code
- Documentation or changelog updated if user-facing behavior changed
- Deployed to staging and smoke-tested
Revisit it every quarter, not every sprint — the whole point is that it stays stable enough to be trusted. If your team keeps arguing about whether something belongs in the DoD or the AC, that's usually a sign the DoD hasn't been written down at all — it's still living in one person's head, which is where the trouble in this piece started.
A diagnostic checklist for your next sprint
Before your next planning session, run your board through these questions:
- Can every engineer on the team recite your DoD from memory, or does it live in a wiki page nobody opens?
- Do your tickets have a separate field for acceptance criteria and DoD, or one shared "requirements" box?
- In the last sprint, how many stories moved backward out of "Done"? What did they have in common?
- Does your DoD include anything that's actually subjective ("good UX," "clean code")? Rewrite those as checkable items.
- Who last updated your DoD, and was it the team that has to follow it?
If two or more of these expose a gap, that's your next retro topic — not a new process, just clarity on which list a given requirement belongs to.
The takeaway
Definition of done and acceptance criteria solve different problems, and the moment a team stops distinguishing them, "done" starts meaning whatever gets a ticket off the board fastest. Acceptance criteria protect the story. Definition of done protects the codebase. Neither is optional, and neither substitutes for the other.
The fix isn't more process — it's usually just writing the DoD down somewhere the whole team owns, and giving each ticket a second checklist instead of asking one checklist to do two jobs. Once "done" has a specific, checkable meaning, the arguments about it mostly disappear — and so does the pattern of the same ticket bouncing between columns three times before it actually ships.
Frequently asked questions
Is acceptance criteria part of the definition of done?
No — they're complementary but separate. Acceptance criteria are specific to one story and written before work starts. Definition of done applies to every story on the board regardless of what it does. A story needs to satisfy both before it's actually finished, but they live as two separate checklists, not one nested inside the other.
Who is responsible for writing the definition of done?
The delivery team — engineers, QA, and often the scrum master or tech lead — because they're the ones who have to hit it every sprint. Product owners typically own acceptance criteria since those describe user-facing value. A DoD imposed by management or copied from another team rarely gets consistently followed.
How is definition of done different from a definition of ready?
Definition of ready is a checklist applied before a story enters a sprint — confirming it's estimated, has clear acceptance criteria, and has no unresolved dependencies. Definition of done is applied at the other end, confirming the work is actually complete. Ready gates what enters the sprint; done gates what leaves it.
Can acceptance criteria change after a sprint starts?
It happens, but it should be rare and treated as a scope change, not a silent edit. If acceptance criteria shift mid-sprint without the team acknowledging it as new scope, you get the same "moving target" problem that erodes trust in the definition of done — the story's bar keeps changing after the estimate was made.