Blog
Definition of Done in Agile: The Three-Level Model
Published on
August 4, 2026
Pricing
%20in%20Agile.jpg)
Definition of Done, often shortened to DoD, is the agreed standard a team commits to before any piece of work can be declared complete.
The Definition of Done in Agile is a shared commitment, not a checklist. The point was never to enumerate tasks, it was to settle what the team is willing to defend when somebody asks "are you really done?" A modern Definition of Done operates at three nested levels, namely story, sprint, and release, embeds testing criteria at each, and amends the classical list for an environment where code is generated faster than humans can review it. The reframe practitioners are making replaces the single flat checklist with a layered commitment that survives an audit, a regulator, and a post-incident review.
The failure it prevents is a specific and familiar one. A product team running two-week sprints marks every story done at the end of a sprint, the board is green, the retrospective is positive, and three days later the support queue spikes because customers in two regions cannot complete a renewal workflow. The defect came from a story marked done, and every item in the Definition of Done had been checked, namely unit tests passed, code was reviewed, acceptance criteria were met, the story was demonstrated. What the Definition of Done did not require was a workflow-level test confirming the change had not broken the renewal sequence. The story was done by its own definition. The product was not.
Done is not a shared word, it is a shared standard, and without the standard the word means whatever the person saying it needs it to mean. What follows sets out the discipline behind it, namely the canonical concept, the three nested levels mature teams operate, the testing criteria that belong at each level, the modern amendments AI-accelerated development demands, and a practical template you can adapt for your own team.
Definition of Done, often shortened to DoD, is the agreed standard a team commits to before any piece of work can be declared complete. In Scrum it is one of the foundational artefacts, and in Kanban, Extreme Programming, and other Agile variants it carries the same role under different names.
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. The intent is operational rather than ceremonial, namely that every story, every sprint, and every release passes through the same gate, owned by the team and enforced consistently.
Three properties characterise a Definition of Done that actually works, and the absence of any one is where most teams' versions start to slip.
A Definition of Done that lives in a wiki nobody reads is decoration. One that lives in the team's habits and is enforced at every commit is infrastructure.
Most teams operate a single Definition of Done. Mature teams operate three, nested, each commitment binding the level above and below. The pattern is not exotic, it is what experienced practitioners do quietly, and the vocabulary is rarely written down, which is why teams new to Agile so often end up with a flat checklist that protects a story but not a release.
The standard a single user story must meet before it can be marked complete, answering whether this piece of work met the team's baseline for any contribution to the product. Typical criteria include code complete, unit tests written and passing, code reviewed with context, acceptance criteria met and verified, no new defects above the agreed severity threshold, documentation updated where user-facing behaviour changed, and the story demonstrated to the Product Owner.
The level is necessary and not sufficient, because a team operating only here ships sprints full of surprises.
The standard the whole increment must meet before the sprint closes, answering whether the stories hold together once integrated. Typical criteria include all story DoDs met, integration tests passing across the sprint's stories, workflow-level tests passing for any customer journey the sprint touched, cross-team dependencies validated, the sprint goal demonstrated, and technical debt resolved or explicitly logged.
The level catches what story-level misses, namely interactions, since two stories can each be done alone and break each other together.
The standard the release candidate must meet before production, answering whether the work is safe to put in front of customers at scale with the regulatory and operational obligations attached. Typical criteria include all sprint DoDs met, the full regression suite executed and passing, critical workflows verified end to end on the release branch, performance and security thresholds met, verification evidence captured and stored, a rollback plan documented and tested, release notes published, and named stakeholder sign-off. The level is where governance lives.
Done at story level, done at sprint level, done at release level. Three commitments, one team, and the work compounds so the release gate stays light because the sprint gate is solid and the sprint gate stays light because the story gate is solid.
A persistent debate in Agile communities is whether testing belongs in the Definition of Done or in acceptance criteria. The honest answer is both, in different ways.
Acceptance criteria define what makes a specific story satisfactorily delivered and are story-specific, while the Definition of Done defines what makes any story, sprint, or release complete and is team-wide.
One answers "what does success look like for this story," the other answers "what standard does the team apply to every piece of work."
Three reasons put testing criteria in the Definition of Done rather than relying on acceptance criteria alone.
The criteria below are the testing criteria that belong in a Definition of Done for a serious product team, organised by the three levels so each block can be copied straight into the matching team artefact.
The floor for any single piece of work, where none of these is optional.
The floor for the increment, adding the cross-story dimensions story-level checks cannot cover.
The floor for production, the criteria that turn an increment into a release the team can defend.
The discipline is to operate all three levels concurrently. A story is not closed unless its DoD is met, a sprint is not closed unless its DoD is met, and a release is not promoted unless its DoD is met.
Three concepts share a vocabulary and answer different questions, and confusion between them produces poorly defined workflows and patchy quality.
The standard a story must meet before it can be pulled into a sprint, defining when work is ready to start rather than when it is finished. Typical criteria are that the story is estimated, its acceptance criteria are defined, its dependencies are identified or resolved, design artefacts are available, and it is small enough to complete within the sprint. It answers whether the team can pick this up confidently.
The story-specific conditions that must be met for the work to count as satisfactorily delivered, written per story by the Product Owner with the team, usually in a when-precondition, if-action, then-outcome form. They are testable and unique to the story, and they answer whether this particular story delivered what was asked.
The team-wide standard that applies to every story, sprint, and release, independent of the specific work, answering whether the work meets the team's baseline for any contribution to the product.
The clearest mental model is that Definition of Ready is the entrance gate, acceptance criteria are the proof for a specific story, and the Definition of Done is the exit gate that applies to every story. A team operating all three without confusion is a team that knows what it is shipping.
The classical Definition of Done was designed for a world where humans wrote code and review capacity scaled roughly with output. AI-accelerated development pushes the input rate up and the effective review capacity down at the same time, so the Definition of Done has to absorb the shift. Five amendments belong in a current DoD.
"Code reviewed" used to imply a human author and a human reviewer, and with assistants producing material portions of contributions that assumption breaks. The amended criterion is that every AI-assisted block is reviewed by a human with context on what it is meant to do, not stamped through because the change set passed lint.
Unit tests verify functions and behaviour tests verify workflows, and when functions are being rewritten by agents on a weekly cadence, workflow-level verification is the only layer that survives. The amended criterion is that workflow-level tests pass for every customer journey a sprint or release affects.
Test platforms with self-healing adapt automatically to UI and structural drift, and the risk is that a healing decision which should have been a defect quietly absorbs into a green build. The amended criterion is that every self-healing decision in the window is logged and reviewable, with substantive healings surfaced for engineering judgement.
Audit-grade evidence used to be a release-day chore, and with regulators arriving and AI-coded systems under formal scrutiny, evidence captured at the moment of verification is the only defensible posture. The amended criterion is that every test run produces evidence as a by-product, indexed against the release identifier and stored for the required retention period.
Running the whole regression suite on every pull request is too slow when they land hourly, and skipping regression is too risky when AI is rewriting large blocks. The amended criterion is that regression scope is selected by change-impact analysis, with tests covering affected customer-critical workflows required to run and tests covering unaffected areas deferred with the deferral logged.
Done in a modern shop is not what humans wrote and reviewed. It is what the team can defend when AI wrote the code and the regulator wants the evidence.
A take-home asset you can adapt for your own team, three layers with the testing-relevant criteria distilled.
The template is not the point. The discipline of enforcing what it lists, through CI and review gates, published in the team's working space and adapted to local context, is the point, and a team that does so has in the act of doing so lifted its release confidence substantially.
Six failure modes show up repeatedly in audits of DoD practice, and naming them is usually the first step to fixing them.
It exists in the wiki, gets referenced in onboarding, and is never enforced, so stories are marked done without checking against it.
The remedy is to enforce it in CI where possible with failing builds on unmet criteria, in pull-request templates where automation is not available, and in working agreements where neither applies.
Defined at team formation and never revisited, so three years in it reflects priorities that no longer apply.
The remedy is a quarterly review on the calendar and a follow-up after every material incident.
A DoD listing "tests written" without a level leaves the substance unspecified, so the story passes on a single trivial unit test and breaks at workflow level.
The remedy is explicit criteria at unit, integration, and workflow level, each named and each enforced.
Every story ends up with its own version of done, consistency collapses, and audit becomes impossible.
The remedy is a clean separation, since DoD applies to every story and AC applies to specific stories, and neither substitutes for the other.
It passes unit tests and fails workflows, because it was never updated for a world where the unit-level signal is decoupling from product-level health.
The remedy is explicit workflow-level criteria at sprint and release level, treated as first-class rather than optional.
Stories pass because a tool reviewed the code and the tool reports no issues because it was trained on the patterns the AI was trained to produce, so human context never enters the loop.
The remedy is explicit criteria for AI-assisted contributions, namely human review with context rather than stamp-through.
A Definition of Done is a living artefact, and three practices keep it useful over time.
The hardest DoD criteria to satisfy are the outcome ones, namely workflow verification and captured evidence, because they are exactly what breaks under maintenance and sprawls across disconnected tools. That gap widens as AI writes more of the code, and it is where the platform is aimed. A few design decisions map directly onto a current DoD.
Every AI action is proposed for review, executed by a deterministic engine, and recorded, so the autonomy stays governed, and the tests run across a broad cross-browser grid.
Enterprises including London Market Group and AerCap use the platform to keep their outcome-based criteria enforceable as the code underneath keeps changing, so the team can answer "are you really done?" with documentation rather than a defensive sigh.
Try Virtuoso QA in Action
See how Virtuoso QA transforms plain English into fully executable tests within seconds.
