Acceptance criteria, Definition of Done, exit criteria: three terms, three questions

There is a scene that plays out in almost every project. Shortly before the release, five people are sitting together and someone asks: “Are we done?” The developer says yes, the code is merged. The business department says no, that is not what was meant. The tester says three cases are still open, but perhaps they do not matter. And the project manager tries to turn three different answers into one decision.

The cause is almost never carelessness. It is terminology. All three answer correctly, simply to different questions. And nobody wrote down beforehand which question is the decisive one.

Three terms, three levels

Scope is the key. An acceptance criterion applies to a requirement and defines the expected outcome. A Definition of Done sets a shared quality standard for an increment. Exit criteria apply to a test phase and determine whether that phase can close. Mixing all three into a single document produces a list that is either too coarse or too specific for any individual case.

Acceptance criteria: the business side

Acceptance criteria describe how the team can determine whether a requirement or user story meets the intended business outcome. The business side remains accountable for the desired outcome, but strong acceptance criteria are often developed collaboratively with developers and testers so that they are clear, complete and testable. In collaborative approaches such as ATDD, missing acceptance criteria are explicitly analysed, discussed and written by the team.

Four properties separate a usable criterion from a decorative one:

• Verifiable. You must be able to picture a procedure that establishes unambiguously whether the criterion is met or not. “The interface is intuitive” is not a criterion. “A user with no prior knowledge completes the order in no more than four steps” is one.
• Binary. No “largely”, no “essentially”. A criterion that can be partially met merely moves the decision into a discussion.
• With a number where a number is meant. “Performant” means something different to everyone. “Response time under two seconds with fifty concurrent users” means the same thing to everyone.
• With the negative case. Most criteria describe the happy path. The damage occurs in the error case. What happens on invalid input, on timeout, on double submission? A set of criteria without negative cases is half a requirement.

The ISTQB syllabus places the corresponding test level unambiguously: “Acceptance testing focuses on validation and on demonstrating readiness for deployment, which means that the system fulfills the user's business needs.” Acceptance is therefore not about whether something works technically, but about whether it meets the business need. That is a different examination from system testing, and it needs different criteria.

Definition of Done: the craft side

The Definition of Done comes from Scrum, where it is defined precisely. The Scrum Guide 2020 states: “The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.” It therefore describes a state, not content. It says nothing about whether the right function was built. It says whether what was built is in a state fit for release.

Two further sentences from the Scrum Guide are routinely overlooked in practice. The first concerns 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. Instead, it returns to the Product Backlog for future consideration.” That is not a recommendation but a hard rule. A Definition of Done without this consequence is a wish list.

The second concerns ownership: “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. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.” The organisational standard is the floor, not the ceiling. A team may be stricter, not more lenient.

What typically belongs in it: code review completed, static analysis with no critical findings, unit tests green, test cases written and executed for the story, no open defects of high or critical severity, documentation updated, the change running in the test environment. What does not belong in it are statements about the business content of a particular story. Those live in the acceptance criteria.

Exit criteria: the test-management perspective

Exit criteria answer the question of whether a test phase may be closed. They are set out in the test plan and therefore belong to test management, and they are the reason a test plan has to exist before testing begins. The ISTQB syllabus covers them alongside entry criteria in the section on test planning.

Typical exit criteria are coverage levels, defect counts by severity, open risks and the completeness of the evidence. What matters is not the selection but the timing: setting the threshold only once the numbers are known is not setting a threshold, it is describing the outcome. Once the results are known, thresholds have a habit of moving. That is exactly why they need to be agreed in advance.

The counterpart is the Definition of Ready: the conditions under which a requirement may enter implementation at all. Without it, the test team starts working with requirements that have no verifiable criteria yet, and writes test cases against assumptions.

How the three work together

The chain is straightforward once the terms are kept apart:

• The acceptance criteria of a requirement provide the template for the test cases. A criterion without a matching test case is unverified; a test case without a matching criterion has no justification. This mapping is exactly what a requirements traceability matrix makes visible.
• The Definition of Done ensures that every increment arrives in a testable state in the first place. Without it you test against moving targets and mostly measure your own waiting time.
• The exit criteria decide whether the phase is closed and feed the release evidence. They are the only one of the three levels on which residual risk is discussed.

The four most common mistakes

• A Definition of Done without consequence. A checklist that is waived when it becomes inconvenient costs time and produces no quality. Either it applies, or it should be deleted.
• Acceptance criteria that repeat the requirement. If the story says “the user can sign in” and the criterion says “the user can sign in”, nothing has been gained. The criterion has to describe the evidence, not the wish.
• Done without evidence. “Tested” is not a state but an assertion for as long as no result is documented. The difference only shows up in an audit or when something goes wrong, and then reliably.
• Thresholds adjusted after the fact. The moment a limit is moved because it would otherwise be breached, it was never a limit. Where there are good reasons for the adjustment, they belong in writing and must be decided by the same authority that owns the release.

Who does what

The business side remains accountable for the intended outcome, while acceptance criteria are often developed collaboratively with development and test. The development team owns the Definition of Done within its Scrum context; test management defines and governs the exit criteria for the test phase. Qelivia supports all three by reviewing acceptance criteria for testability, helping structure a robust Definition of Done and defining measurable exit criteria in the test plan. Your team executes the tests; Qelivia provides the structure, review and evidence.

Conclusion

“Are we done?” is not one question but three. Whether the right thing was built is answered by the acceptance criteria. Whether it was built cleanly is answered by the Definition of Done. Whether enough was verified is answered by the exit criteria. Separate the three and agree them in advance, and the release discussion becomes a review of evidence rather than a debate about definitions.