Acceptance criteria

1 Acceptance Criteria in Software and Product Development

1.1 Definition and purpose

Acceptance criteria are specific conditions that determine whether a product deliverable, feature, or user-facing behavior is considered complete and satisfactory. They convert broad intent into concrete, observable outcomes so teams can evaluate results consistently.

Their primary purpose is alignment: stakeholders gain a shared understanding of what “done” means, while engineering and testing gain a clear target for verification. By reducing ambiguity, acceptance criteria also help prevent scope drift and clarify what evidence is sufficient for sign-off.

1.2 Relationship to requirements and user stories

Acceptance criteria sit between high-level requirements and implementation details. Requirements describe goals, capabilities, or constraints; user stories express value from a user perspective; acceptance criteria define how to verify that the story’s outcome is achieved.

A common pattern is that each user story includes acceptance criteria for the story’s core value, supplemented by additional criteria for constraints such as data correctness, error states, and relevant non-functional needs.

1.3 Stakeholders and who uses them

Acceptance criteria are used by multiple roles across the lifecycle:

• Product owners or managers use them to define satisfactory outcomes and support prioritization and budgeting decisions.
• Engineers use them to guide implementation choices and determine what needs instrumentation, logging, or validation.
• Testers and QA teams use them as the basis for test design and coverage planning.
• Designers and UX stakeholders use them to confirm that interaction and messaging meet expectations.
• Operations or support teams may reference them to anticipate deployment readiness and user impact.

1.4 When acceptance criteria are written

Acceptance criteria are typically authored early—during planning or backlog refinement—so that the team can estimate effort and plan verification. However, they often evolve as discovery uncovers edge cases, integration constraints, or user feedback.

In agile workflows, acceptance criteria may be revised during implementation as teams learn what is feasible and as additional scenarios become necessary for safe release. The key is that final sign-off should rely on the latest agreed criteria, not outdated assumptions.

2 Writing Effective Acceptance Criteria

2.1 Clarity and specificity

Good acceptance criteria are readable and precise. They focus on outcomes rather than internal methods, and they provide enough detail to eliminate different interpretations among stakeholders.

2.1.1 Measurable outcomes

Criteria should be tied to observable results such as response codes, changes in system state, calculated values, UI behavior, or measurable performance thresholds. Measurability enables consistent verification and reduces the risk of subjective acceptance.

For example, instead of saying a “valid page loads,” a strong criterion specifies what “loads” means (e.g., required fields render, no blocking errors appear, and the page displays expected content).

2.1.2 Unambiguous wording

Ambiguity arises when terms like “fast,” “works,” or “properly” are used without definitions. Effective criteria replace vague language with concrete descriptions of expected behavior.

Unambiguous wording also clarifies scope: which user roles, which platforms, which time windows, and which data conditions are covered.

2.1.3 Avoiding hidden assumptions

Acceptance criteria should explicitly state assumptions that could otherwise be missed during verification. Examples include required authentication context, assumed feature flags, supported locales, or prerequisites for data availability.

Hidden assumptions often surface as repeated test failures or late-stage disagreement, making early clarity a practical investment.

2.2 Testability and verification

Acceptance criteria should be structured so that a tester—or an automated system—can verify compliance using a known procedure and expected outcomes.

2.2.1 Linking criteria to tests

Each acceptance criterion should correspond to one or more test cases. Even when the system is verified through demos or reviews, the evidence should map cleanly to the stated condition.

When teams anticipate multiple verification approaches (automated tests, manual exploratory sessions, or inspection of logs), criteria should still describe the observable evidence that proves satisfaction.

2.2.2 Expected results format

A consistent “expected results” format helps reduce variance across reviewers. Criteria often specify what the system returns, displays, persists, or triggers, including how it behaves under normal and exceptional conditions.

Where relevant, specifying thresholds, counts, time bounds, and validation rules makes outcomes easier to confirm.

2.3 Using common templates and formats

Templates help teams write consistent, complete criteria. The goal is not rigid formality, but repeatable structure.

2.3.1 Given-When-Then structure

The Given-When-Then pattern separates context, the triggering action, and the expected outcome. It supports clarity, especially for user flows and system behaviors with multiple preconditions.

This structure also encourages teams to enumerate scenarios rather than bundle unrelated behaviors into a single statement.

2.3.2 Checklist-style criteria

Checklist-style acceptance criteria are common for features with multiple independent requirements. Each item can be verified separately, which can improve coverage and reduce the risk that one missing detail blocks acceptance.

Checklist criteria work best when each item is sufficiently self-contained and not dependent on vague interpretation.

2.3.3 Scenario-based criteria

Scenario-based criteria describe a sequence of interactions or events, often covering realistic user journeys. They are particularly useful when multiple steps influence a final outcome.

The challenge is to avoid overly long scenarios that conceal multiple distinct requirements; well-structured scenarios identify the success checkpoints clearly.

3 Structure and Components

3.1 Context and preconditions

Every acceptance criterion benefits from specifying when it applies. Preconditions define the state the system and the user must be in for the scenario to be meaningful.

3.1.1 Preconditions and setup steps

Preconditions may include user authentication, the existence of required records, feature toggles being enabled, or the presence of specific configuration.

Setup steps are particularly helpful when verification relies on consistent test data. Clear preconditions prevent testers from compensating with guesswork.

3.2 Actions and triggers

Criteria should identify what causes the behavior: a button click, an API call, a message submission, a scheduling event, or a background job completion.

The trigger should be described at a meaningful level of abstraction, avoiding “how the system is built” while still making it clear what input or action initiates the expected outcome.

3.3 Expected outcomes

Expected outcomes describe both the result and how it appears or changes system state.

3.3.1 Success conditions

Success conditions specify what “passing” looks like: fields updated, correct calculations performed, correct UI displayed, or a successful status returned. These conditions should include relevant details such as identifiers, formats, or values.

3.3.2 Failure conditions

Failure conditions are equally important for completeness. They describe expected behavior when the system cannot complete the requested action, including status codes, error codes, user messaging, and whether partial side effects occur.

Well-defined failure conditions reduce ambiguity and help prevent silent errors that might otherwise go unnoticed.

3.4 Data and constraints

Acceptance criteria often include rules about correctness, validation, and permissible ranges.

3.4.1 Input validation expectations

Criteria should state which inputs are accepted, which are rejected, and how the system responds to invalid data. Validation expectations commonly cover required fields, data types, allowed character sets, and maximum lengths.

Including validation behavior in acceptance criteria ensures that data integrity is treated as part of “done,” not as an afterthought.

3.4.2 Formatting and edge rules

Systems frequently need to enforce formatting rules such as date formats, numeric precision, casing, or locale-specific behavior. Acceptance criteria should cover these requirements and note edge rules like trimming whitespace, handling leading zeros, and interpreting boundary inputs.

3.5 Performance and non-functional acceptance

Non-functional acceptance criteria translate operational expectations into measurable or inspectable conditions. These criteria reduce risk by defining what performance and robustness mean for the release.

3.5.1 Latency, throughput, and limits

Performance criteria may specify response time ranges, acceptable load levels, maximum concurrent requests, or limits for batch processing. They should include the conditions under which the metrics are measured, such as test environment characteristics or load test setup.

When strict numbers are infeasible, criteria can still define relative expectations (e.g., “no worse than baseline under specified load”), as long as the measurement method is clear.

3.5.2 Reliability and resilience expectations

Reliability and resilience criteria may describe retry behavior, graceful degradation, handling of transient failures, timeouts, and fallback mechanisms.

Including expectations about system behavior during partial outages or dependency instability helps teams avoid releases that function only in ideal conditions.

4 Coverage and Completeness

4.1 Happy path vs. edge cases

Acceptance criteria should cover the primary scenario—the “happy path”—and also relevant edge cases that commonly break correctness or user experience.

A practical approach is to identify likely failure points such as missing inputs, boundary values, unexpected state transitions, and integration anomalies. Edge cases do not need exhaustive coverage, but they should be prioritized based on risk and user impact.

4.2 Error handling expectations

Error handling criteria define how the system behaves when it cannot fulfill a request. This includes both technical outcomes and user communication.

4.2.1 User-friendly error messages

Error messages should be understandable and actionable. Acceptance criteria can specify that messages indicate what went wrong, which fields are affected, and what the user can do next.

Where applicable, criteria may also require that errors avoid exposing sensitive internal details while still providing sufficient information for resolution.

4.2.2 Retry and recovery behavior

For operations involving external services, network calls, or background tasks, acceptance criteria can specify how the system handles transient issues. This may include controlled retries, idempotency guarantees, and the expected end state when retries are exhausted.

Recovery expectations also include whether users can proceed after an error and whether the system maintains consistency.

4.3 Boundary values and limits

Boundary conditions—minimums, maximums, and thresholds—often determine correctness. Acceptance criteria should specify expected behavior at these limits, including how the system rounds, caps, rejects, or defaults.

Covering boundaries prevents defects like off-by-one errors and inconsistent validation.

4.4 Security and privacy considerations general

Acceptance criteria may include general, non-controversial expectations such as not leaking confidential data in responses or logs, applying appropriate access checks, and ensuring secure handling of sensitive inputs.

Where security requirements exist, acceptance criteria should phrase them in terms of observable behavior (e.g., unauthorized requests are rejected; sensitive fields are masked; audit events are generated).

4.5 Accessibility-related expectations general

Accessibility-related acceptance criteria translate inclusive design goals into testable outcomes. These can include keyboard navigation, focus behavior, readable labels, sufficient contrast, and screen-reader compatibility.

4.5.1 Usability and interaction requirements

Usability criteria may address interaction consistency and clarity, such as deterministic form validation timing, predictable navigation patterns, and meaningful affordances.

Even when not all accessibility standards are applied, acceptance criteria can still specify key interaction behaviors that affect real users.

5 Acceptance Criteria Lifecycle

5.1 Drafting during planning

During planning, teams draft acceptance criteria that capture the intended value and principal constraints. This early version supports estimation, prioritization, and a preliminary verification plan.

Drafting at this stage encourages early alignment and reduces the chance that the implementation proceeds without an agreed definition of completion.

5.2 Refinement with discovery and feedback

Discovery activities—such as user interviews, technical exploration, and design review—often reveal additional scenarios. Acceptance criteria are refined to include missing edge cases, clarify ambiguous wording, and adjust thresholds or constraints.

Feedback from stakeholders helps ensure that criteria represent actual needs rather than assumptions.

5.3 Updating during implementation

While coding progresses, teams may uncover new dependencies, integration behaviors, or performance characteristics that require updates. Acceptance criteria can change, but updates should be governed by review and mutual agreement to avoid surprise at the end of the sprint.

Pragmatically, teams may also add criteria to support instrumentation, logging expectations, or operational readiness based on what becomes visible during implementation.

5.4 Sign-off and final verification

Sign-off confirms that the deliverable meets the agreed criteria. Verification evidence may include test results, demo recordings, peer reviews, and inspection outputs.

A strong practice is to freeze the acceptance criteria used for sign-off or maintain versioned changes so that stakeholders can trace what was evaluated.

5.5 Traceability and documentation

Traceability connects acceptance criteria to requirements, user stories, and test artifacts. This helps audits, retrospective learning, and future maintenance.

Documentation also supports continuity when teams change: new contributors can understand what “done” meant and why specific checks exist.

6 Common Mistakes and How to Avoid Them

6.1 Vague criteria

Vague criteria use subjective language without definitions. They create disagreement during verification because different reviewers may interpret outcomes differently.

To avoid this, teams should define measurable results, include relevant constraints, and specify observable evidence.

6.2 Overly broad criteria

Overly broad acceptance criteria bundle multiple behaviors into a single statement, making it hard to determine whether partial completion counts. Such criteria can also hide missing edge cases.

Breaking broad statements into smaller, testable items improves coverage and supports more reliable acceptance decisions.

6.3 Mixing “how” with “what”

Criteria sometimes describe implementation approaches rather than outcomes. When teams focus on method, they restrict design flexibility and can lead to acceptance that is tied to technical choices instead of user value.

Acceptance criteria should prioritize outcomes and observable behavior, leaving internal design decisions open unless constrained by explicit requirements.

6.4 Criteria that aren’t verifiable

Some criteria may be written in terms of intent without specifying evidence. If a criterion cannot be tested or inspected, it undermines the acceptance process.

A remedy is to ensure each criterion includes either a measurable condition, a clear inspection method, or an expected artifact such as a log entry or UI element.

6.5 Conflicting or duplicated requirements

Conflicts occur when acceptance criteria contradict each other, or when duplicate criteria overlap with different expectations. These issues can cause inconsistent test results and confusion at sign-off.

Teams can reduce this by reviewing criteria for coherence, consolidating duplicates, and checking that each criterion maps cleanly to a specific behavior.

7 Acceptance Criteria and Testing

7.1 Mapping criteria to test cases

Acceptance criteria should directly inform test case design. Mapping establishes which tests validate each criterion and helps confirm that all required behaviors are exercised.

When mapping is explicit, teams can identify gaps early and avoid discovery of missing coverage late in release cycles.

7.2 Manual vs. automated verification

Both manual and automated verification can be used. Automated tests are effective for repeatable checks such as validation rules, computed outputs, and regression coverage. Manual verification can be helpful for exploratory UX evaluation, workflow usability, and visual inspection where automated checks are insufficient.

Acceptance criteria should remain compatible with both approaches by defining observable outcomes that can be confirmed via either method.

7.3 Demo scripts and inspection

For stakeholder review, demo scripts can operationalize acceptance criteria by walking through the scenarios and showing evidence. Inspection-based verification may include reviewing generated reports, configuration outputs, or system logs.

Criteria should specify what the demo must demonstrate and what evidence constitutes proof, such as a visible success message or a computed metric.

7.4 Regression implications

Acceptance criteria influence regression strategy because they define what must not break in future changes.

7.4.1 Ensuring prior behavior remains valid

If acceptance criteria are clear and comprehensive, regression tests can be derived from them. This reduces the likelihood that a future release alters behavior while still appearing “mostly working.”

A practical strategy is to retain tests mapped to acceptance criteria and to expand regression coverage when new edge cases are discovered.

8 Examples and Practice

8.1 Simple example (feature behavior)

A web feature allows users to create a support ticket. An acceptance criterion could state: when a user submits the form with all required fields populated, the system creates a ticket and displays the ticket ID on the success screen.

Verification evidence would include the new ticket appearing in the ticket list and the UI showing the expected ID.

8.2 Example set with edge cases

For the same support ticket feature, acceptance criteria can include edge cases such as invalid input and missing required fields. For example:

• Given a user is on the ticket creation page, when they leave the message body empty and submit, then the form displays a validation message for the message field and the ticket is not created.
• Given the user enters a message longer than the allowed maximum, when the user submits, then the system rejects the submission and indicates that the message exceeds the limit.

These criteria cover both normal completion and common input failures, enabling targeted testing.

8.3 Example non-functional criteria (general)

A background export job generates a CSV file from selected records. Non-functional acceptance criteria might specify: when the export is triggered with a dataset of up to a defined size, the system starts the job within an agreed time window and completes within a specified duration.

The criteria should also define measurement conditions, such as using a representative environment and recording start and completion timestamps.

8.4 Reviewing and improving sample criteria

Reviewing sample criteria involves checking for clarity, completeness, and verifiability. Teams can improve criteria by:

• Replacing vague wording with explicit observable outcomes.
• Splitting combined behaviors into separate statements.
• Ensuring each criterion includes success and failure expectations where relevant.
• Confirming that a test or inspection method exists for each criterion.

Peer reviews can also catch hidden assumptions, such as missing preconditions or unspecified user roles.

8.5 Checklist for quality of acceptance criteria

A quality checklist can include the following items:

• Each criterion states an observable outcome.
• Preconditions and triggers are specified.
• Success and failure conditions are covered as appropriate.
• Criteria are testable and map to test cases or demo evidence.
• Language avoids internal implementation details.
• Criteria do not conflict with one another.
• Non-functional considerations are included when relevant.
• The set is complete enough to support consistent sign-off.