Product writing guide

Acceptance criteria examples that teams can test

Acceptance criteria turn a broad request into observable outcomes. They give product, engineering and QA the same definition of done before work begins.

What makes acceptance criteria useful?

Useful criteria describe behavior, not implementation. A tester should be able to confirm each point without guessing what “easy,” “fast,” or “works well” means. Include the happy path, validation rules and meaningful failure states.

• Use a specific user, trigger and expected outcome.
• State the conditions that must be true before the action.
• Cover boundaries such as invalid input, permissions and unavailable services.
• Keep technical design decisions out unless they are a requirement.

Example: password reset

Feature: Reset a forgotten password

Scenario: Send a reset link for a registered account
Given a user is on the forgotten-password page
When they submit an email address for a registered account
Then the system confirms that a reset email has been sent
And the email contains a single-use reset link

Scenario: Protect account privacy
Given a user submits an email address
When that address is not registered
Then the system shows the same confirmation message
And it does not reveal whether an account exists

Scenario: Reject an expired link
Given a reset link has expired
When the user opens the link
Then the system asks them to request a new link

Example: checkout address

Scenario: Save a valid delivery address
Given a signed-in customer has items in their basket
When they enter all required delivery fields and save
Then the address is saved to the order
And the checkout can continue to delivery options

Scenario: Explain invalid postcodes
Given the customer enters an unsupported postcode
When they attempt to continue
Then the postcode field displays a clear validation message
And the order is not submitted

A quick review checklist

1. Could QA turn each criterion into a test case?
2. Does every rule describe a visible outcome?
3. Are error and permission paths covered where they matter?
4. Does the set match the user story’s value without adding unrelated scope?