Acceptance Criteria Template

Acceptance criteria are the conditions a feature has to meet to be accepted, written so that someone who was not in the planning meeting can check them. This template covers all four kinds a spec usually needs: behaviour, things that must not happen, quality thresholds, and, when a model decides the output, an evaluation that holds over many runs.

When you need one

Use this template when a feature is about to be built or tested by people other than you, and the criteria section of the spec is thin, scattered across tickets, or written as adjectives. It also works as the structure for the criteria section inside a PRD, if you would rather not keep a separate document.

Skip it for a copy change, a one-line bug fix or anything where the ticket already states a single observable outcome. And do not write criteria for work whose premise could still be rejected. That is the expensive way to discover it is not happening.

For the reasoning behind the functional half, read how to write testable acceptance criteria. The model-behaviour section is explained in acceptance criteria for non-deterministic features.

The template

# [Feature] — Acceptance Criteria
Spec: [link to PRD] · Owner: [name] · QA owner: [name] · Last updated: [date]

## Scope of these criteria
Covers: [requirement IDs or stories]
Not covered here: [what is verified elsewhere, and where]

## Definitions
- [Term a tester could read two ways]: [exact meaning, with a number
  if it has one. "Large workspace" = more than 5,000 members.]

## Functional criteria

### [REQ-ID] — [requirement name]
Scenario: [name of the success case]
  Given [starting state, including the data it needs]
  When [one action]
  Then [observable result]

Scenario: [name of a failure or edge case]
  Given [starting state]
  When [one action]
  Then [observable result, including what happens to the user's work]

## Negative criteria
- [What must NOT happen or be visible, and to whom]

## Non-functional criteria
| Attribute | Criterion | Condition | Measured by |
|---|---|---|---|
| [Performance] | [p95 under N ms] | [load and data size] | [tool or dashboard] |

## Model-driven behaviour
(Only when a model decides the output. Delete otherwise.)
Evaluation set: [name, version, number of cases, who labelled them]
Grading rule: [what counts as a pass for one case]
Threshold: [minimum pass rate over the set]
Baseline: [current system or human agreement, or TBD with a reason]
Floors: [minimum pass rate for each segment you care about]
Hard lines: [outcomes that fail the release on one occurrence]
Runs: [how many runs, and how results are combined]
Owner: [who owns the set, the threshold and new cases]

## Instrumentation
- [event_name]: fires when [condition]; confirms [criterion]

## Open questions
- [Question] — Owner: [name] — Needed by: [date]

Section by section

Scope of these criteria

A one-line boundary that stops two documents from each assuming the other covers something.

Definitions

Most untestable criteria are untestable because of one word. Define it once, here, and use it consistently below.

Functional criteria

One scenario per condition you care about, written so that the Then line is the assertion. Write the failure scenarios before the success ones; the success case writes itself and nobody files a bug against it.

Negative criteria

Requirements about absence: a panel members cannot see, a field that must not appear in an export. Nothing shows on screen when they work, which is why they go unwritten and untested.

Non-functional criteria

Quality thresholds with a number, a condition and a place they are measured. Without all three, a non-functional criterion is an opinion.

Model-driven behaviour

Only for output a model decides. Given-When-Then assumes one input gives one output; a model does not, so the criterion becomes a statement about a set of cases.

Instrumentation

The events that let someone confirm the criteria hold in production, not just in QA.

Open questions

Worked example

Three sections from criteria for a feature that lets workspace admins export the member list to CSV.

Definitions

• Admin: a member with the Owner or Admin role in this workspace. Billing contacts are not admins.
• Removed member: a member whose access was revoked, at any time.

Functional criteria — REQ-3, export

• Admin exports a large workspace. Given a large workspace and a signed-in admin, when the admin selects Export members, then a CSV download starts within 30 seconds, containing one row per current member.
• Export service fails. Given a signed-in admin, when the export request returns a server error, then the admin sees "Export failed, nothing was downloaded" with a retry option, and no partial file is saved.

Negative criteria

• Removed members never appear in the file.
• A member without the Admin or Owner role does not see the Export option.
• Email addresses of members who opted out of directory visibility are not included.

The failure scenario and the negative criteria are doing most of the work here. The opt-out line in particular is a privacy decision a tester would never have guessed.

The deliberate weakness: "Given a large workspace" is used in the first scenario and never defined. QA will test against whatever the seed script produces, which may be a few dozen members, and the 30-second criterion will pass for a case nobody cares about. The fix goes in Definitions: Large workspace: [TBD: set from the largest current account, data team to confirm by 14 Oct]. A stated known-unknown with a reason and a date is rigor. An undefined adjective in a Given line is a test that measures nothing.

Common mistakes

Adjectives in the Then line. "Quickly", "clearly", "gracefully". Replace each with the thing a test could check, or move the line to the non-functional table with a number.

Criteria that cannot fail. If no realistic build would fail the criterion, it is not constraining anything. Ask what a wrong implementation would look like and whether the criterion would catch it.

Only the success path. The revoked invite, the expired session and the failed dependency are the week-one bugs. Write those scenarios first.

No negatives. Permission and data-exclusion rules are invisible when they work, so they are the criteria most often missing and the failures most likely to become incidents.

Copies in tickets. One canonical set, linked by requirement ID. Pasted copies drift and nobody can tell which is current.

A pass rate with no baseline. For model-driven behaviour, a threshold chosen without knowing today's number, or how consistently people agree on the labels, is a guess dressed as a standard.

Run it through a review

Engineering Readiness and Edge Case & QA Drill are the two passes in Thinkr's critique that read acceptance criteria and the failure cases they should cover.