Product writing guide

How to write acceptance criteria that teams can test

Good acceptance criteria turn a broad feature request into observable behavior. They help product, engineering, and QA agree on what “done” means before development starts.

What are acceptance criteria?

Acceptance criteria are the conditions a feature must meet before a team accepts it. They describe what a user can do, what the system must do, and what should happen when something goes wrong. They are not implementation tasks or a full technical design.

A useful criterion is specific enough for QA to test and simple enough for a stakeholder to understand. If two people would test it differently, it needs more detail.

Use this five-step method

1. Start with the user outcome

State the value the feature should deliver. For example: “A registered user can request a password reset.” This keeps the criteria focused on the problem rather than on a button, database field, or API choice.

2. Make the starting condition clear

Describe what must already be true. Does the user need to be signed in? Does the account need to exist? Is a required permission needed? Clear context prevents assumptions during development and testing.

3. Describe one action at a time

Write the action a user or system takes. Keep separate flows separate: a valid request, an invalid request, and an expired link should usually be different scenarios.

4. Specify an observable result

Describe what someone can see, receive, save, or verify. Replace vague phrases such as “works correctly” or “is user friendly” with a visible result, validation message, saved record, or access change.

5. Include meaningful boundaries

Cover error, validation, permission, and privacy cases where they matter. You do not need every theoretical edge case, but you should document the rules that affect a user, a business decision, or a test plan.

Worked example: password reset

The following example is testable because each scenario has a clear starting state, action, and result.

Feature: Reset a forgotten password

Scenario: Send a reset link to a registered user
Given a registered user has forgotten their password
When they submit the email address linked to their account
Then the system confirms that a reset link was sent
And the reset link expires after 30 minutes

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

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

Review checklist

• Can a tester verify every criterion without asking for more information?
• Does each criterion describe a user-visible result or business rule?
• Are invalid input, permission, and failure paths covered where needed?
• Are the criteria free from unnecessary technical implementation details?
• Do the criteria support the actual value promised in the user story?