A digital initiative may be technically deployed and still not be ready for business approval. The reverse can also happen: the outcome appears useful, but an important dependency, permission, or exception remains unresolved. Often, this is because different stakeholders use the word “done” to mean different things.
Defining acceptance criteria before work begins helps everyone agree on the expected outcome, how it will be checked, and who has the authority to approve it. This does not replace scope definition or technical testing; it connects the business need to an observable acceptance decision. This framework helps product, business, and technology leads reduce disagreements and identify gaps before delivery.
Separate objectives, scope, and acceptance criteria
These three elements answer different questions. The objective explains why the work is being undertaken and what change it aims to achieve. The scope sets out what will be addressed and what is excluded. Acceptance criteria describe the verifiable conditions used to decide whether a specific outcome meets the agreement.
For example, an objective might be to make it easier for customers to check the status of their orders. The scope might include a status page for active orders but exclude changes to the delivery address. An acceptance criterion could specify that entering a valid identifier displays the corresponding status and the date it was last updated. This example does not prescribe how to build the page or define the entire project by itself. It sets out a condition that must be possible to verify.
Before drafting criteria, confirm that the objective is clear and that the scope has explicit boundaries. If a need is not included, do not leave that exclusion implicit. Clarifying it helps prevent a later expectation from being treated as a defect in a deliverable that was never intended to address it.
Write observable conditions, not prescribed solutions
A useful criterion can be checked through an action, an observable result, or agreed evidence. Avoid phrases such as “easy to use,” “fast,” or “works correctly” unless their meaning is clarified in the context of the product. These are worthwhile intentions, but they leave room for incompatible interpretations.
Instead of saying “the lookup must be intuitive,” define the task the user must be able to complete and the result that confirms completion. If the objective includes performance, accessibility, or security, translate each expectation into a condition that is relevant to the use case and establish how it will be evaluated. Do not invent thresholds for convenience: agree on values with the people who understand the need and the constraints.
It is also worth avoiding technical prescriptions when the business needs only an outcome. “Use a blue button” is usually a design decision, not a functional acceptance condition. By contrast, “the user can start the lookup from the orders page” describes a capability that can be validated without unnecessarily ruling out implementation alternatives.
A practical way to write a criterion is to include four components:
- Context: the situation or type of user being considered.
- Action: what must happen or what task must be possible.
- Outcome: the response, change, or information that should be observable.
- Verification: the evidence that will confirm the outcome.
Not every criterion needs the same structure. What matters is that business, product, and technology stakeholders can interpret it consistently and explain how to distinguish acceptance from non-compliance.
Cover workflows, exceptions, permissions, and dependencies
The main workflow is a good starting point, but it is rarely enough. A definition that covers only the ideal case may leave unanswered what happens when data is invalid, no results are found, permissions are insufficient, or an external service is unavailable. Include edge cases that affect the expected outcome, the risk, or the approval decision.
To identify these cases, walk through the experience from the perspective of users and operations:
- What happens if a required field is missing or has an unsupported format?
- What information can each user role view, and which actions are they not allowed to take?
- How is the user told that there are no results or that an operation could not be completed?
- Which external dependency could prevent validation, and who is responsible for resolving it?
- Are there intermediate states, such as a pending request, that need to be distinguished from confirmation?
There is no need to list every imaginable situation. Prioritize exceptions that affect security, compliance, operational continuity, user experience, or scope. If a dependency is unavailable during acceptance, agree in advance on what alternative evidence is acceptable and what risk remains open. For example, a demonstration using prepared data does not automatically validate a live integration; that distinction should be clear.
Assign owners and evidence before work starts
A criterion with no validation owner can reopen the debate at the end. For each condition, identify who proposes the need, who carries out or coordinates the check, and who makes the acceptance decision. In some teams, these responsibilities belong to different people; in others, they may overlap. The key is to make approval authority unambiguous.
Also define what evidence will support the decision: a behavior review, a log, a demonstration, a test result, or confirmation from a responsible stakeholder. The evidence must match the criterion. A screenshot may show a page, but it may not prove that permissions are being applied correctly. A technical test may confirm a response, but not necessarily that the information is understandable to the intended user.
A short template for each criterion could include:
- Identifier and description: a unique, specific condition without vague terms.
- Context and scope: the user, state, or situation covered, and any excluded exceptions.
- Acceptance owner: the person or role that makes the decision.
- Method and evidence: how the condition will be checked and where the result will be recorded.
- Status and notes: accepted, pending, or not accepted, with a reason and next step.
The template should not become documentation for its own sake. If the record does not help people make decisions, coordinate work, or retain evidence, simplify it.
Manage changes and identify ambiguity
Criteria may change when new information emerges. To avoid surprises, record what changed, who approved it, and how it affects scope, priority, dependencies, and the expected date. Distinguish a clarified criterion—which makes an already agreed expectation explicit—from a new criterion that adds behavior. The latter may expand the scope and calls for a decision, not a silent change to the definition of done.
Before accepting a deliverable, look for signs of ambiguity. Phrases such as “must be complete,” “as appropriate,” or “without errors” do not say what to check. Other warning signs include criteria that combine several independent outcomes, have no owner, depend on a third party without a plan, or fail to specify what should happen if something goes wrong. Split mixed conditions, make the outcome specific, and agree on how dependencies will be handled.
If business and technology stakeholders disagree about a criterion, return to the need and the risk it is meant to address. Ask what evidence would change the decision and what alternative could meet the objective without prematurely prescribing a solution. If the issue cannot be resolved before work begins, record it as an open decision, assign an owner, and set a date for resolution. Do not hide it inside a generic phrase.
A good acceptance criterion cannot guarantee the success of an initiative on its own, but it makes approval more predictable. When every condition describes an observable outcome, has an owner, and is supported by suitable evidence, teams can identify disagreements earlier, distinguish defects from scope changes, and decide more clearly whether something is truly done.