Definition of Done in Agile: Levels, Criteria & Template

The Definition of Done in Agile isn’t really a checklist. It’s a promise. It’s what your team is willing to stand behind when someone asks, “Are you really done?”

Here’s the problem it solves. A team runs two-week sprints and marks every story done at the end of one. The board is green and the retro goes well. Three days later, support tickets spike because customers in two regions can’t complete a renewal.

The bug came from a story marked done. Everything in the Definition of Done had been ticked: unit tests passed, the code was reviewed, acceptance criteria were met and the story was demoed. What it didn’t ask for was a test of the whole renewal journey. So the story was done by its own definition, but the product wasn’t.

“Done” only means something if everyone agrees on what it means.

What is Definition of Done in Agile?

The Definition of Done (DoD) is the standard your team agrees work must meet before it counts as complete.

In Scrum, it’s the commitment that comes with each Increment. The Scrum Guide describes it as a formal description of the state of the Increment once it meets the quality measures the product needs. Other Agile approaches, like Kanban, use similar ideas, often as explicit policies for when work can move to “done”.

The point is practical, not ceremonial. Every story, sprint and release goes through the same gate, owned by the team and applied every time.

A Definition of Done that works has three things going for it:

• Shared: everyone on the team knows it, agrees with it and uses it.

• Standard: it applies to every piece of work, not negotiated story by story.

• Stable but up to date: steady enough to enforce, but reviewed every quarter or after a big change, not rewritten every week.

If your DoD lives on a wiki page nobody opens, it won’t do much. It needs to show up in pull requests, CI checks and sprint reviews to make a difference.

The Three Levels of Definition of Done

Most teams have one Definition of Done. Good teams have three, each building on the one before. It’s not complicated, and experienced teams often do it without writing it down. That’s why teams new to Agile often end up with one flat checklist that protects a story but not a release.

‍You need the story level, but if that’s all you check, expect surprises at the end of every sprint. The sprint level picks up problems caused by stories clashing with each other. The release level is where sign-offs, evidence and rollback plans come in.

If the story checks are done properly, the sprint checks don’t take long. And if the sprint checks are done properly, the release checks don’t either.

Why Testing Belongs in the Definition of Done

Agile teams often debate whether testing belongs in the Definition of Done or in acceptance criteria. The honest answer is both, but in different ways.

Acceptance criteria say what success looks like for one specific story. The Definition of Done says what standard the team applies to every story, sprint and release.

Here’s why testing needs to be in the DoD, not just in acceptance criteria:

• Consistency: Acceptance criteria change from story to story, so testing based on them alone ends up patchy. One story gets solid testing, the next gets none. The DoD sets a minimum for everything.
  
  

• Problems between stories: Some bugs only appear when story A and story B are combined. Acceptance criteria for single stories can’t catch those. Sprint and release DoDs can.
  
  

• Something you can show people: Acceptance criteria are spread across the backlog. The DoD is one named, dated standard you can show an auditor, a regulator or a post-incident review.

Testing Criteria for the Definition of Done in Agile

Here are the testing criteria a serious product team should include, sorted by level so you can copy each block straight into your own DoD.

1. Story-Level Testing Criteria

The minimum for any piece of work. None of these are optional.

• All new code has unit tests, written by the person who wrote the code. AI-assisted code is held to the same standard.

• Unit tests pass locally and in the CI pipeline.

• Acceptance criteria are checked with tests that run, not just confirmed by hand.

• At least one other engineer who understands the change reviews the code. AI-written code is reviewed by someone who knows what it’s meant to do, not just waved through.

• The story doesn’t add any bugs above the agreed severity level.

• Docs are updated if the change affects APIs, what users see or how things are run.

2. Sprint-Level Testing Criteria

The minimum for the sprint as a whole, covering what story-level checks can’t.

• Every story in the sprint meets the story-level DoD.

• Integration tests for the affected components all pass.

• Tests pass for every customer journey the sprint’s changes touched.

• Any automatic test fixes made during the sprint have been reviewed, if your tools make them.

• Dependencies on other teams are sorted out or written down.

• The sprint goal is shown working in a real environment, not in screenshots.

3. Release-Level Testing Criteria

The minimum for going to production, turning a sprint’s work into a release you can stand behind.

• Every sprint in the release meets the sprint-level DoD.

• The full regression suite runs against the release candidate and passes within the agreed bug limits.

• Key customer journeys are tested end to end on the release branch, not just on feature branches.

• Performance, accessibility and security checks run and meet the agreed thresholds.

• Evidence, including test runs, coverage reports, performance results and security scans, is saved against the release number.

• There’s a rollback plan, and it’s been tested in staging.

• Release notes are written and approved by the Product Owner and the technical lead.

• Named owners give sign-off. Silence doesn’t count as approval.

All three levels run at the same time. A story isn’t closed until its DoD is met, a sprint isn’t closed until its DoD is met, and a release isn’t promoted until its DoD is met.

If your release checklist includes journey tests, have a look at how Virtuoso QA handles end-to-end testing across screens, APIs and data.

Definition of Done vs Acceptance Criteria vs Definition of Ready

These three get mixed up a lot, and the confusion leads to messy workflows and patchy quality.

A team that uses all three, without mixing them up, knows exactly what it’s shipping.

What AI Changes in the Definition of Done

The classic Definition of Done was built for a world where people wrote the code and review capacity grew roughly in line with output.

AI changes that.

Code arrives faster, while the time people have to review it stays the same. Here are five updates your DoD needs.

AI-Written Code Needs a Real Human Review

“Code reviewed” used to mean one person wrote it and another checked it. With AI writing a lot of the code, that assumption doesn’t hold.

Every AI-assisted change should be reviewed by someone who understands what it’s meant to do, not passed just because it got through linting.

Journey Testing is a Must at Sprint and Release Level

Unit tests check functions. Journey tests check workflows. When AI agents are rewriting functions every week, journey-level testing is the layer that holds up. Tests should pass for every customer journey a sprint or release affects.

Automatic Test Fixes Must Be Visible

Some testing tools fix tests automatically when the UI changes. The risk is that a fix quietly hides something that should have been a bug, and the build goes green anyway.

Every automatic fix should be logged and reviewable, with bigger ones flagged for someone to check.

Evidence is Captured as You Go, Not Pieced Together Later

Pulling together evidence used to be a release-day chore. With regulators paying closer attention to AI-written systems, the only safe approach is to capture evidence at the moment tests run.

Every test run should produce evidence automatically, saved against the release number and kept for as long as you need it.

Regression Scope is Based on Risk

Running the whole regression suite on every pull request is too slow when they come in every hour. Skipping regression is too risky when AI is rewriting big chunks of code. So choose regression scope based on what changed: tests for affected customer journeys must run, and tests for unaffected areas can wait, with that decision logged.

Not sure how to decide what counts as high risk? Our guide to risk-based regression testing walks through scoring features by likelihood and impact, and how much testing each level should get.

So these days, “done” has to cover more than “someone wrote it and someone else looked at it”. It has to hold up when part of the code came from AI and someone asks to see proof it was tested.

Definition of Done Template

Here’s a template you can copy and adapt for your team.

The template itself isn’t the point. Enforcing it is. Build it into CI and review gates, keep it where the team works and adapt it to your situation. Teams that actually do this see a big jump in how confident they feel about releases.

Common Definition of Done Mistakes

How to Keep Your Definition of Done Up to Date

After a year of this, your DoD reflects the real risks in your product, because every incident has taught it something.

Also read: our guide to agile testing covers how testing fits into each sprint.

How Virtuoso QA Helps You Meet Your Definition of Done

The items teams struggle with most are usually the journey tests and the evidence. Here’s how Virtuoso QA lines up with the checklist above:

• Journey tests for your sprint and release items: A single Virtuoso QA test can walk through a customer journey on screen and confirm the API responses and database records behind it, so those items get ticked by tests you’re already running.
  
  

• Acceptance criteria turned into tests: if your story-level DoD says acceptance criteria must be checked with automated tests, Touchstone can take the criteria from your Jira stories and turn them into draft tests that point back to the exact criterion they came from. Nothing goes into the suite until someone on your team signs it off.
  
  

• No silent test changes: The sprint item about reviewing automatic test fixes is easy to keep up with, because Virtuoso QA doesn’t change a test on its own. If a screen changes, it flags the fix it wants to make, waits for a yes or no, and keeps a note of the answer.
  
  

• Evidence already in place at release time: There’s nothing to gather at the end. Each run stores the screenshots, the result, the requirement the test covers, who approved the test and which build it ran on. If a run fails, that same record is what the root cause analysis works from.
  
  

• Your Selenium suite still counts: If you already have Selenium tests, GENerator can convert them into plain English, so you don’t lose the regression coverage your release DoD depends on.

The AI only ever proposes changes. A deterministic engine runs the tests and keeps a log, so your team still decides what counts as done. Tests can run in parallel on more than 2,000 browser and OS combinations.

Next time someone asks if a release is really finished, you can open Virtuoso QA’s release evidence and show them what was tested, against which requirement, and who approved it.

Related Reads

• ‍What is Agile Testing? Principles, Types & Practices‍
  
  

• 12 Advantages of Agile Testing for Modern QA Teams‍
  
  

• Top 20 Agile Testing Tools for QA Teams in 2026‍
  
  

• 24 Agile Test Metrics Every QA Team Should Know‍
  
  

• ‍Agile Test Automation: Strategies for Sprint Success‍