·
9 min
Definition of Done: Meaning, Example and How It Differs from Acceptance Criteria
Roman Kirchmeier - Autemos
The Definition of Done (DoD) is a Scrum Team's binding quality agreement: it lists the checks an Increment has to pass before anyone can call it done. The Scrum Guide 2020 calls it the commitment for the Increment. Banks give the DoD a second job. It carries test obligations from the EU's DORA regulation or FINMA Circular 2023/1 into every Sprint. A good DoD separates pipeline checks from manual ones and covers AI-generated code.
TL;DR: The Scrum Guide 2020 defines the DoD as a formal description of the state every Increment must reach. It covers all backlog items, acceptance criteria cover one story, and the Definition of Ready isn't in the Guide. In banks, regulatory minimums belong in it, such as DORA Art. 9(4)(e)'s rule that every ICT change is recorded and tested.
Figure 1: When an Increment counts as done
What is the Definition of Done?
The Definition of Done is a formal quality description that applies to every Increment a Scrum Team produces and states when work is finished. The Scrum Guide says: “The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.” (Scrum Guide 2020, 2020)
The same section states the consequence: “If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review.” (Scrum Guide 2020, 2020) The item returns to the Product Backlog, and the Guide says Developers “are required to conform to the Definition of Done.”
A usable DoD has a few traits:
It applies the same way to every backlog item, whether feature, bug fix or technical task.
It's set at team or organization level and stays fairly stable across Sprints, per a Professional Scrum Trainer on Scrum.org (2024).
Every item has a yes-or-no answer and visible evidence.
DoD vs acceptance criteria vs Definition of Ready: what differs?
The DoD applies to every Increment, acceptance criteria apply to one user story, and the Definition of Ready is a team practice for letting a story into a Sprint. Only the DoD appears in the Scrum Guide 2020; the other two don't appear there at all (Scrum Guide 2020, 2020).
Figure 2: DoD, acceptance criteria and DoR compared
Aspect | DoD | Acceptance criteria | Definition of Ready |
|---|---|---|---|
Scope | Every Increment, every backlog item | One user story | One story before Sprint Planning |
In the Scrum Guide 2020 | Yes, the commitment for the Increment | No | No, the Guide only describes refinement |
Set by | Organization as a minimum, then the Scrum Team | Product Owner with team and stakeholders | Team, optional |
Example item | “Regression tests for affected functions pass” | “Transfer above the daily limit is rejected” | “Dependencies on other teams resolved” |
ISTQB view | Exit criteria (CTFL §5.1.3) | Test conditions (CTFL §4.5.2) | Entry criteria (CTFL §5.1.3) |
Typical risk | Items without evidence | Only positive cases described | Turns into a stage gate |
The syllabus places the DoD too: “In Agile software development, exit criteria are often called Definition of Done, defining the team's objective metrics for a releasable item.” (ISTQB CTFL v4.0.1, 2024)
Acceptance criteria come from requirements engineering; the ISTQB Foundation syllabus says they “may be viewed as the test conditions that should be exercised by the tests” (ISTQB CTFL v4.0.1, 2024). See our guide to acceptance criteria for user stories for testable criteria with positive and negative scenarios.
Mike Cohn treats the DoD as a special set of acceptance criteria added to every user story (Mountain Goat Software, 2024). On the Definition of Ready, he warns it can push teams into “a sequential, stage-gate approach” (Mountain Goat Software, 2016). If you use a DoR, keep it short, as a refinement aid.
Why do regulatory duties belong in a bank's DoD?
In a bank, the organization-wide DoD is where regulatory minimums for testing and change control reach every Sprint. The Scrum Guide supplies the rule: “If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum.” (Scrum Guide 2020, 2020)
Figure 3: Change management under the DORA Regulation (EU) Art. 9(4)(e)
For financial entities in the EU, the DORA regulation (EU) 2022/2554 has applied since 17 January 2025. Art. 9(4)(e) requires ICT change management policies so that “all changes to ICT systems are recorded, tested, assessed, approved, implemented and verified in a controlled manner” (EUR-Lex, DORA, 2022).
Delegated Regulation (EU) 2024/1774 is more concrete. Art. 16 requires a procedure for “testing and approval of all ICT systems prior to their use and after maintenance”. Art. 17 requires the approving function to be independent of the implementing one (EUR-Lex, RTS 2024/1774, 2024).
Swiss banks fall under FINMA Circular 2023/1, in force since 1 January 2024. Its ICT risk management part requires testing functional and non-functional requirements according to criticality (FINMA Circular 2023/1, 2022). DORA reaches a Swiss bank only through EU subsidiaries or services provided in the EU.
As DoD items for a bank team:
Every change is recorded in a ticket and linked to its tests.
Tests are selected by criticality, executed and stored as evidence.
Approval comes from someone who didn't implement the change.
After maintenance or a hotfix, the affected tests run again.
The DoD makes the organization's policy minimums checkable story by story. Linking requirement, test case and result turns the word “tested” into evidence.
What does a definition of done example look like?
A usable DoD example separates items the CI pipeline checks automatically from items people check. Tooling enforces the first group; the second needs discipline and visible evidence. This checklist fits a bank's Scrum Team building a web application with a REST API.
DoD item | Check type | Evidence |
|---|---|---|
Unit and integration tests pass | Automated in the pipeline | Pipeline run |
Regression tests for affected functions pass | Automated in the pipeline | Test report, result on the ticket |
Story's acceptance criteria turned into tests and passed | Automated, rest manual | Link from story to test case |
Negative tests for new input fields pass | Automated in the pipeline | Test report |
Static analysis with no high-severity findings | Automated in the pipeline | Analysis report |
Code review by a second person | Manual, tool enforces approval | Approval in the merge request |
Exploratory test of the story in a fixed timebox | Manual | Session note |
No open high-severity defects | Manual | Defect list |
Change recorded, approved by someone who didn't implement it | Manual | Audit trail on the ticket |
Cohn's own example item reads: “The code comes with automated tests at all appropriate levels” (Mountain Goat Software, 2024). Negative tests for new inputs belong in the pipeline; our negative testing guide shows how to derive them. The exploratory test stays manual, with a fixed timebox per story and a short note of findings.
“Regression tests pass” costs the most to maintain. Every UI change can break tests that are correct in business terms. Your regression testing scope decides whether this item holds Sprint after Sprint or becomes an excuse.
Which DoD items does AI-generated code need?
AI-generated code needs its own DoD items: a human review of every generated change and automated tests that run before the merge. The data comes from Google Cloud's DORA research program (DevOps Research and Assessment), unrelated to the EU regulation of the same name.
In the 2024 DORA report, a 25% increase in AI adoption was associated with a “1.5% decrease in delivery throughput” and a “7.2% reduction in delivery stability” (Google Cloud, 2024 DORA Report, 2024). The 2025 report, with about 5,000 respondents, found 90% use AI at work and 30% have little or no trust in AI-generated code (Google Cloud, 2025 DORA Report, 2025).
The researchers name strong automated testing, mature version control and fast feedback loops as controls. Without them, “an increase in change volume leads to instability” (Google Cloud, 2025 DORA Report, 2025). That gives four DoD items:
A person has read every AI-generated change and approved it in the merge request.
The merge request marks which parts came from an AI assistant.
A person has reviewed tests for generated code before they join the suite.
The existing regression suite passes before the merge.
How is the DoD different from a quality gate?
The Definition of Done is a team agreement about the state of the Increment, and a quality gate is an automated pipeline rule that stops a broken build. A gate enforces the automatable part; exploratory tests, business reviews and second-person approval stay with the team.
Figure 4: Which DoD items the quality gate checks and which the team checks
According to the DORA research program, running tests continuously in a pipeline “contributes to quick feedback for developers, a short lead time from check-in to release, and a low error rate in production environments” (DORA, Test Automation, n.d.). Good thresholds are covered in our article on quality gates in CI/CD; for the pipeline setup, read about test automation in CI/CD.
Autemos, selementrix's AI-assisted test automation software, cuts the maintenance effort for one DoD item: “Regression tests pass”. When a locator loses its element after a UI change, Autemos self-healing steps in; every heal is documented and reversible.
Autemos syncs test results both ways with Jira and Xray, so the evidence sits on the ticket. Autemos doesn't cover the DoD itself, acceptance criteria, load and performance testing, security and penetration testing or code coverage.
How do you introduce a DoD?
You introduce a Definition of Done in five steps, from your organization's minimum standard to a regular team review.
Adopt the minimum standard. Check whether your organization prescribes one, for example in its change management policy. If it doesn't, the Scrum Guide says the Scrum Team “must create a Definition of Done appropriate for the product.” Several teams working on one product share one DoD.
Add team items. Items that fit the product, such as accessibility of a web interface.
Make every item checkable. Replace vague items like “code is clean” with measurable ones like “static analysis shows no high-severity findings”.
Move what's automatable into the pipeline. What a tool can check becomes a quality gate; the rest gets evidence on the ticket.
Review it regularly. If items break Sprint after Sprint, change the list or the way you work.
Common DoD mistakes
Story-level requirements end up in the DoD instead of the acceptance criteria.
Items quietly drop at Sprint end. Per the Scrum Guide, the item then goes back to the Product Backlog.
The Definition of Ready becomes a barrier that holds stories outside the Sprint for weeks.
The list contains items nobody checks or records.
Frequently asked questions
Is the DoD mandatory in Scrum?
Yes, the Scrum Guide 2020 requires Developers to conform to it as the commitment for the Increment. A Product Backlog item that doesn't meet it can't be released or presented at the Sprint Review and returns to the Product Backlog (Scrum Guide 2020, 2020).
What is the difference between the DoD and acceptance criteria?
The DoD applies to every Increment; acceptance criteria apply to one user story. The DoD covers product-wide quality measures such as passing regression tests. Acceptance criteria describe a story's business behavior, and the ISTQB CTFL v4.0.1 syllabus treats them as test conditions the tests should exercise (ISTQB CTFL v4.0.1, 2024).
Is the Definition of Ready part of the Scrum Guide?
No, the Definition of Ready doesn't appear in the Scrum Guide 2020. The Guide only says items the team can finish in one Sprint “are deemed ready for selection in a Sprint Planning event.” Mike Cohn warns a rigid DoR can lead to a stage-gate approach (Mountain Goat Software, 2016).
Does the EU DORA regulation apply to Swiss banks?
Since 17 January 2025, the DORA regulation applies directly only to financial entities in the EU. It reaches Swiss banks through EU subsidiaries or EU services. Swiss banks are governed by FINMA Circular 2023/1, in force since 1 January 2024, which sets requirements for ICT risk management (FINMA Circular 2023/1, 2022).
Can a DoD be checked automatically?
Partly: a CI quality gate checks tests, static analysis and build rules automatically. Checks that need human judgment stay manual, such as exploring a story or the four-eyes sign-off. The DORA research program links continuously running tests to a short lead time from check-in to release (DORA, Test Automation, n.d.).
Conclusion
The Definition of Done states which quality measures every Increment has to meet, and the Scrum Guide 2020 makes it binding. It covers all backlog items. Acceptance criteria describe the single story; the Definition of Ready is an optional team practice. In banks, the organization-wide DoD carries the regulatory minimums: record changes, test them, approve them independently and retest after maintenance. Separate what a quality gate checks from manual and exploratory items, and for AI-generated code, add human review and passing tests before the merge. If you want to keep “Regression tests pass” green with documented self-healing and results on record in Jira and Xray, talk to the Autemos team.
