Most agile teams ship work that "passes acceptance criteria" but isn't actually done — and most teams "complete" sprints with stories that never met the definition of done. The confusion between acceptance criteria vs definition of done is one of the most common, and most expensive, gaps in scrum. It causes silent rework, missed quality bars, broken releases, and the slow erosion of trust between developers, product owners, and stakeholders.
This guide ends that confusion. You'll get the precise difference between acceptance criteria and definition of done, real examples for both, the boundary failures that cause the most rework, and how AI tooling in 2026 is reshaping how teams write, validate, and enforce both.
What's the difference between acceptance criteria and definition of done?
Acceptance criteria define what a specific user story must do to satisfy the user; definition of done defines what every piece of work must meet to be considered complete. Acceptance criteria answer "did we build the right thing?" — they are story-specific, owned by the product owner, and validated per item. The definition of done answers "did we build it right?" — it is universal across the product, owned by the developers, and applied to every backlog item before it ships.
That distinction is simple in theory. In practice, the boundary is where most quality problems live.
What is acceptance criteria in agile?
Acceptance criteria (AC) are the specific conditions a single product backlog item must satisfy for the product owner — and ultimately the user — to accept it. They describe the external behavior of the feature: what the user can do, what the system must produce, what edge cases must be handled.
Acceptance criteria are:
Story-specific. Each user story has its own set.
Owned by the product owner, drafted collaboratively with developers and testers.
Written before development starts, refined during backlog refinement, and locked before sprint commitment.
Validated throughout the sprint — they guide development and testing in real time.
A clean set of user story acceptance criteria for a "user can reset password via email" story might look like this:
Given a registered user enters a valid email, when they submit the reset form, then a password reset email is sent within 60 seconds.
The reset link expires 30 minutes after issuance.
Submitting an unregistered email shows a generic confirmation message (no account enumeration).
The new password must meet the existing password strength policy.
The user is automatically logged in after a successful reset.
Notice the format. Many teams use Given/When/Then (a Gherkin-style structure borrowed from BDD) for behavior-heavy stories and plain bullets for simpler rules. Both work. What matters is that each criterion is testable, unambiguous, and tied to user value.
Who writes acceptance criteria?
The product owner drafts the first version, but acceptance criteria are written with developers and QA, not handed to them. The Three Amigos pattern — PO, developer, tester — is the most reliable way to surface ambiguity before it becomes rework. A 20-minute Three Amigos session per story prevents most "but you didn't say…" disputes at sprint review.
What is the definition of done in scrum?
The scrum definition of done (DoD) is a shared, team-wide standard for what "complete" means for any product backlog item. It is the team's quality contract with itself. If a story does not meet the DoD, the increment is not done — regardless of whether its acceptance criteria are met.
The DoD is:
Universal. It applies to every PBI in the product, from a typo fix to a new feature.
Owned by the developers. They define and maintain it; the scrum master facilitates it.
Stable but evolving. It changes when the team's quality bar genuinely shifts (new test coverage standards, new security requirements), not story by story.
Applied at the end of work to assess completeness, not used as a writing guide for stories.
A typical software DoD includes:
Code is peer-reviewed and merged to main.
Unit and integration tests are written and passing.
Automated acceptance tests cover all acceptance criteria for the story.
Static analysis and security scans pass.
Documentation (user-facing and internal) is updated.
The change is deployed to staging and smoke-tested.
All known regressions are resolved.
The product owner has accepted the work in a working environment.
Per the 2020 Scrum Guide, every increment delivered to the sprint review must meet the definition of done — that is non-negotiable. Across Scrum.org community discussions and State of Agile reporting, a missing or weak DoD is one of the most consistent indicators of a team that ships unreliable increments.
Acceptance criteria vs definition of done: 7 key differences
If you remember nothing else: AC is what; DoD is how well. AC describes the user-visible behavior of one story. DoD describes the engineering and quality bar across all stories.
Why teams confuse acceptance criteria and definition of done — and what it costs
The confusion is not academic. It produces measurable rework. Teams running broken agile implementations consistently show three failure patterns.
1. AC swallows DoD. Teams stuff testing, code review, and deployment requirements into every story's acceptance criteria. Stories balloon, refinement drags, and the team still misses universal quality steps because they are buried in 40-line AC blocks. The DoD never gets owned because it is duplicated everywhere.
2. DoD swallows AC. Teams write a beautiful, stringent DoD — and then write user stories with one or two vague acceptance criteria like "user can log in." Developers technically meet the DoD (tests pass, code reviewed, documented) but ship behavior the product owner did not want, because no one defined what "log in" actually means. The result: cosmetic completeness, business-level failure.
3. Both exist but neither is enforced. The DoD lives on a wiki page nobody reads. Acceptance criteria are copy-pasted from old stories. The team marks stories "done" on velocity, but the product owner rejects them at review. Sprint over sprint, completion rates lie.
A useful diagnostic: ask any developer on your team to recite three items from the DoD without looking. Then ask the product owner to show the acceptance criteria for the most recent story they accepted. If either answer is fuzzy, you have a quality boundary problem — not a tooling problem.
This is the kind of structural gap FixAgile, an Agile training and implementation framework designed for the age of AI, identifies in its team-level assessments. Most "agile is broken" complaints we see in coaching engagements trace back to this exact boundary collapse.
How AI is changing acceptance criteria and definition of done in 2026
Most competing guides ignore this completely. They shouldn't — AI is changing both artifacts in ways every Scrum Master and Product Owner needs to understand.
AI is generating draft acceptance criteria from product context. Tools embedded in modern backlog systems — Jira's AI features, Linear's auto-AC suggestions, ChatGPT-based PO assistants — now read the user story title, the product spec, and similar past stories, and propose Given/When/Then criteria within seconds. The output is rarely perfect, but it surfaces edge cases humans miss — null states, error paths, accessibility requirements — and turns the PO's job from "write from scratch" into "edit and validate." Teams using this pattern report refinement meetings shrinking from 90 minutes to 30.
AI is automating DoD enforcement. This is the bigger shift. Until 2024, the DoD was enforced by humans noticing things in pull requests and standups. In 2026, CI pipelines integrated with AI-powered code review (GitHub Copilot for code review, Cursor's review agents, CodeRabbit) automatically check whether a PR satisfies DoD items: test coverage thresholds, accessibility audits, security scans, documentation updates, changelog entries. The DoD has become executable rather than aspirational.
AI is closing the loop between AC and DoD. Modern tooling can read a story's acceptance criteria, generate the matching automated tests, run them as part of the DoD gate, and report compliance back into the backlog item. The boundary between "did we build the right thing" (AC) and "did we build it right" (DoD) is still conceptual, but the validation pipeline is now unified.
Three implications for agile teams in 2026:
Your DoD must be machine-readable. Vague items like "tested thoroughly" are dead. Replace them with measurable gates: "≥80% line coverage on changed files," "OWASP top-10 scan passes," "accessibility audit returns no critical findings."
Your AC must be precise enough for AI to test. Ambiguous criteria like "the page should be fast" cannot be automated. "P95 page load under 2 seconds on a 4G connection" can.
The PO and developer roles converge on judgement. When AI handles drafting, validation, and enforcement, the human work shifts to deciding which edge cases matter and what quality bar serves the user. This is exactly the role evolution FixAgile's training programs are built around.
Acceptance criteria examples by user story type
Functional story — checkout flow:
Given a logged-in user with at least one item in the cart, when they click "Checkout," then they are routed to the payment page within 1 second.
The payment page shows a line-item summary, tax, shipping, and total.
A user with no saved payment methods sees the new card form by default.
Submitting an invalid card surfaces the specific field error inline, not a generic "payment failed" toast.
Non-functional story — performance improvement:
The dashboard P95 load time on a desktop 4G connection is ≤ 1.8 seconds (currently 3.4).
The improvement is verified across Chrome, Safari, Firefox, and the latest Edge.
No existing functional tests regress.
Spike or research story:
Spikes typically use a deliverable-based AC instead of behavior:
A written recommendation document covering at least three viable options.
Each option includes pros, cons, integration cost estimate, and a risk assessment.
A go/no-go recommendation is signed off by the technical lead and product owner.
Definition of done examples by team maturity
Forming team (first 90 days of agile):
Code is reviewed by one peer.
Unit tests cover the changed logic.
Acceptance criteria are demonstrably met in a shared environment.
The product owner has seen and accepted the work.
Scaling team (working in SAFe, LeSS, or Scrum@Scale):
All of the above, plus:
Cross-team dependencies have been identified and resolved.
Integration tests across affected services pass.
Telemetry and monitoring hooks are in place for the new behavior.
Release notes are added to the program-level changelog.
AI-augmented mature team:
All of the above, plus:
AI-generated regression tests run against the changed surface area.
Static analysis, security, and accessibility scans pass automatically.
The DoD pipeline reports green in the PR before merge.
Production observability dashboards include the new feature within 24 hours.
The DoD is supposed to harden as the team's capability grows. If your DoD has not changed in the last 12 months, it is almost certainly out of date with what your team is now capable of.
How to write better acceptance criteria
Start with the user outcome, not the implementation. "User receives a confirmation email" beats "system calls SendGrid."
Use Given/When/Then for behavior; bullets for static rules. Mixing them is fine — match the form to the criterion.
Make every criterion testable. If you cannot describe how to test it, it does not belong in AC.
Cover the unhappy paths. Most rework comes from unspecified edge cases. Force yourself to write at least one negative AC per story.
Cap the count. If a story has more than seven acceptance criteria, it is probably two stories. Split it.
Refine in the Three Amigos format. PO, developer, tester. Twenty minutes per story prevents most downstream disputes.
How to build a definition of done your team will actually follow
Co-create it. A DoD imposed by a Scrum Master is theater. Build it with the developers in a 90-minute working session.
Make every item measurable. "Code is reviewed" is weaker than "code is reviewed and approved by a developer who did not write it."
Tie items to automation wherever possible. Anything a CI pipeline can check should not depend on a human remembering.
Review it every quarter. New tooling, new risks, new compliance requirements — the DoD should change deliberately, not drift.
Display it where the work happens. On the board, in the PR template, in the sprint review opening. Out of sight is out of practice.
Where does the definition of ready fit in?
Definition of ready (DoR) is the third member of this family — and it sits before the work, not at its boundaries.
Definition of ready: the criteria a story must meet before it can enter a sprint. Typically: clear AC, sized, dependencies known, designs attached.
Acceptance criteria: the criteria a story must meet to satisfy the user.
Definition of done: the criteria any story must meet to be released.
DoR prevents teams from pulling half-baked work into sprints. AC prevents teams from building the wrong thing. DoD prevents teams from shipping work at the wrong quality bar. Mature agile teams use all three; struggling teams blur or skip them.
The bottom line for AI-era agile teams
Acceptance criteria and definition of done are not interchangeable, not optional, and — in 2026 — not just human concerns. The teams that ship fastest are the ones whose AC and DoD are precise, complementary, and increasingly enforced by AI inside the delivery pipeline. The teams that ship rework are the ones still debating the difference in retros.
If your team's "done" stories keep coming back from review, if your sprints feel productive but your releases keep slipping, or if AI is accelerating your coding without improving your shipped quality, the boundary between acceptance criteria and definition of done is almost always the place to look first. This is exactly what FixAgile's training programs and team-level assessments are built to fix — diagnosing where your AC and DoD are blurring, rebuilding them for AI-augmented delivery, and embedding the practice so it sticks past the engagement.
Get the boundary right, and most of what people call "broken agile" stops being broken.
