What are acceptance criteria?
Acceptance criteria are the specific conditions a piece of work must satisfy for acceptance. They connect the requested change to behavior that a reviewer can inspect. Atlassian describes their role in clarifying expectations around a user story or feature.
A request such as make invitations reliable expresses an aim but leaves important decisions unresolved. A criterion can state what happens when an invitation has expired, which user may replace it, and what the application records after a retry. Those choices help implementation and review focus on the same outcome.
This guide uses three original fictional SaaS examples: invitation expiry, subscription seat limits, and asynchronous report generation. The policies are examples to discuss with your team. They do not describe a real product's permissions or establish requirements for your own service.
Download the review worksheet and evidence register
The worksheet contains the example policies, Given/When/Then scenarios, questions for a review conversation, and a blank drafting form. The CSV connects each criterion ID to a proposed verification method, expected evidence, and an initially pending status.
The examples are criteria and a review plan, not executed tests. Do not relabel a row as passed because its wording looks clear. Record the actual environment, result, and evidence after checking the implemented behavior.
Use the same IDs in the specification, implementation discussion, and review record. That makes it easier to find an uncovered condition when a feature changes. Keep sensitive customer data out of shared evidence files; a synthetic workspace can usually demonstrate these example boundaries.
Distinguish criteria, tests, and a Definition of Done
Acceptance criteria belong to a particular change. A team's Definition of Done sets recurring expectations across work, such as review and documentation. A test describes how to exercise an implementation and inspect a result. These can reinforce each other without becoming interchangeable.
For an expired invitation, the criterion can say that access is not granted at or after the expiry instant. A test might create a fixed-clock invitation, advance time to that instant, submit an acceptance request, and inspect both the response and membership records.
Some criteria need a human review or a research session. Text must be understandable to a first-time administrator cannot be established solely by asserting that a paragraph exists. Define the intended reader, task, and observation method, then use the usability testing guide to plan that evidence.
Keep implementation details out of a criterion unless they are part of the required contract. Naming a particular database helper can unnecessarily constrain a solution; naming the absence of unauthorized membership is an observable security outcome.
Use Given, When, and Then for concrete examples
Given establishes the relevant starting state. When describes the action or event. Then states an observable outcome. Cucumber documents these Gherkin keywords as a way to structure examples. Writing them does not automatically create an executable test; step definitions and an appropriate test environment are additional work.
Keep each scenario focused on one rule. Include an And when it adds necessary state or an outcome, rather than combining unrelated journeys. A short example can reveal a missing product decision more effectively than a long checklist of interface clicks.
For the fictional invitation policy: Given an invitation expires at 12:00:00 UTC, when it is accepted at 12:00:00 UTC, then no membership is created and the user receives the agreed expiry explanation. This explicitly treats equality as expired. A different product may choose another policy, but it must specify the boundary.
Write invitation criteria beyond the happy path
The first example allows an authorized administrator to replace an expired invitation after checking that no active membership already exists. It also requires an unauthorized user to be denied without revealing protected workspace information. Successful replacement must not revive the old token.
Separate permission from visibility. Hiding a button does not prove the underlying action is forbidden. Review the server's authorization decision and the resulting state, using a permitted synthetic account with insufficient privileges.
Replace vague words with a defined observation. Clear error message becomes the agreed explanation is shown without exposing the invitation token. No duplicates becomes a replay of the same accepted request creates no additional membership. Decide which response is expected for the replay as part of your actual API contract.
| ID | Criterion | Proposed verification |
|---|---|---|
| AC-I1 | At or after expiry, no membership is created | Fixed-clock boundary test plus stored-state check |
| AC-I2 | A non-admin cannot replace an invitation | Direct request with restricted role |
| AC-I3 | A replay creates no additional membership | Repeat the same accepted request and inspect state |
Cover seat-limit races and background-job failures
For the seat example, the fictional plan allows ten active memberships. At nine, one authorized activation may succeed. At ten, another activation is rejected with the agreed upgrade or capacity response. The policy counts memberships, not pending invitations, and must say what happens to deactivated users.
Now consider two activations competing for the last seat. A sequential interface test is insufficient. The criterion requires that the committed state never exceeds ten under concurrent requests; the verification plan must exercise the race and inspect final state. The implementation may need an atomic operation or transaction, but the criterion states the invariant.
For report generation, define states the requester can observe: queued, processing, completed, and failed. A completed status means the authorized requester can retrieve the intended result. A worker retry must not create a second charge or duplicate completion notification under the example policy.
Failure deserves a useful outcome too. A failed job should expose an agreed support reference without disclosing private input, and a user from another workspace must not retrieve its output. Specify retention and retry rules separately according to the actual product contract.
Review criteria before committing the work
Ask the product owner, implementer, and reviewer to walk through the examples together. Look for unnamed actors, ambiguous time boundaries, undefined state, and words such as fast or secure without an observation method. Record unresolved choices as decisions to make rather than disguising them as accepted criteria.
Confirm that the proposed evidence could disprove the requirement. A screenshot of a disabled control cannot establish authorization, and one successful job does not establish idempotency. Link each criterion to the check that addresses its actual risk.
Add the accepted criteria to the PRD and retain the dated review record. When behavior changes, update the relevant examples and their evidence together. These downloadable examples were checked for matching IDs and pending verification labels; they are not a claim that a SaaS implementation has passed them. Sources checked October 27, 2026.