Acceptance criteria: examples you can use in Jira

A Jira acceptance-criteria example

Put the criteria in the issue description, or a dedicated field if your Jira project has one. Keep the governing requirement linked. Atlassian’s guidance describes this approach and distinguishes story-specific criteria from a team’s broader Definition of Done.

The example below is a proposed transaction-export story, not a record of executed tests. Have the product owner resolve the intended behavior before using it as an acceptance basis.

Use this plain-text template in your existing documents or issue tracker. No signup needed.

Download the template (.txt)

Story: As an account owner, I want to export selected transactions.
Requirement and revision:
Intent owner and approval state:

AC-1: Given an authorized account owner and selected transactions,
when the export completes, then the file contains exactly those
transaction IDs and their recorded amounts, once each.

AC-2: Given a transaction belonging to another account,
when its ID is included in the request, then the export is rejected
without returning that transaction's data.

AC-3: Given an empty selection,
when export is requested, then no export starts and the user is
asked to select at least one transaction.

AC-4: Given an interrupted export,
when the operation cannot complete, then the user sees a failure
and no partial file is presented as a completed export.

Decisions still needed: supported formats, maximum size,
concurrent edits, retry behavior and timeout expectations.

For each criterion, retain:
Check ID / candidate revision / expected result /
actual result / output link / open gaps

Criteria, tests and “Done” answer different questions

The requirement is the continuing promise. Acceptance criteria make the expected outcomes of this story explicit. The Definition of Done sets the team’s shared completion conditions, such as review and documentation. A test result records what actually happened in a particular execution.

For AC-2 above, checking that a button is hidden would not establish that the export API rejects a cross-account transaction ID. The test needs to exercise that boundary and inspect the response and output. This is where precise wording must become relevant evidence.

When an agent changes the implementation, retain the approved criteria. If it proposes weaker criteria to make a failing test pass, treat that as an intent decision. See how to verify AI-generated code.

Start with the decision

Begin with the user or operator outcome, the relevant starting conditions and the observation that distinguishes acceptable from unacceptable behavior. Include important negative and boundary cases. Keep criteria at the level of the promise: a customer-facing export criterion needs evidence about the delivered export, not only a unit test showing that one formatter works. The approved criterion is the oracle against which the implementation and its tests are assessed.

An illustrative case

Illustrative case: an operator requests a transaction export. “Export works” leaves format, authorization and omission behavior ambiguous. Useful criteria can require an authorized operator to receive exactly the selected records in the agreed format, reject unauthorized requests and preserve record identifiers. Test data should include an empty result and boundary values. If the customer expects a delivery-time limit, agree the conditions and threshold before measuring it.

Build the record

1. Recover the outcome from the request and existing obligations. Resolve conflicts through the applicable approval policy.
2. Write criteria with identifiable inputs, observable results and meaningful failure cases; give each a stable ID.
3. Design an acceptance test of the integrated system for each testable criterion, independent of the implementation’s convenience.
4. Run the tests against the relevant revision and retain the result, environment and limitations. Revisit evidence when the criterion or its implementation basis changes.

How Proof checks the evidence link

For a stakeholder criterion marked testable: true using the default test method, Proof looks for a direct acceptance witness using the annotation // STK-REQ-42:AC-1:acceptance on an eligible test. A nominal unit witness on a derived requirement does not automatically credit the stakeholder criterion. The companion quality check inspects whether a tagged witness has the declared acceptance-test role. Explicit analysis, inspection and demonstration methods have separate evidence requirements; justify why a test is unsuitable when choosing one.

This floor is default-on and normally a warning; missing witnesses can be promoted under audit.evidence_strict. An ordinary witness_deferred reason records visible debt, not a passing witness. KI-linked debt has additional disposition rules. Neither the annotation check nor a configured audit command alone guarantees that a repository blocks merging: the required-check and bypass policy must enforce the result for the current revision.

proof audit --check acceptance_criteria_witnessed

Keep the conclusion bounded

A linked acceptance test is an artifact. Its existence does not establish that it executed, exercised the right path or used a valid oracle. Approval of the criterion, behavioral verification and acceptance of the change are separate decisions. Missing evidence should remain visible rather than turning an untested criterion into a non-testable one.

Continue with one real issue

Acceptance witness quality · Acceptance review current

Bring one finding, its requirement and the current evidence to scope a walkthrough of what your reviewer can establish and what still needs work.