How to Write Acceptance Criteria: Examples & Checklist

Acceptance criteria define what must be true before a user story can be accepted. They reduce rework because the team agrees on behavior, edge cases, and quality expectations before development starts.

Use this guide when you are writing Jira stories, preparing backlog refinement, or turning rough feature notes into testable work. For a faster first draft, use the Acceptance Criteria Generator. For a copy-paste structure, use the Acceptance Criteria Template.

What Are Acceptance Criteria?

Acceptance criteria are clear, testable conditions that a feature must satisfy before the Product Owner, QA, or team can call the story complete.

A good acceptance criterion should answer:

• what context or condition applies
• what action or event happens
• what result should be visible or verifiable
• what errors, permissions, or edge cases matter
• how QA can prove whether it passed or failed

Acceptance criteria are not the same as implementation tasks. "Use Redis for caching" is a technical task. "Search results appear within 500ms for 95% of requests" is acceptance criteria because it describes a measurable outcome.

How to Write Acceptance Criteria in 6 Steps

1. Start with the user story

Read the user story, business value, scope notes, designs, dependencies, and open questions.

If the story does not clearly explain the user and outcome, fix that first. A weak story usually creates weak acceptance criteria.

Useful prompt:

As a [user type],
I want to [take an action],
So that [business or user outcome].

2. Choose the right format

3. Write the happy path first

Start with the normal successful outcome. This gives the team a shared baseline before you add exceptions.

Weak:

User can reset password.

Better:

Given a registered user is on the password reset page,
When they submit a valid account email,
Then a password reset email is sent within 2 minutes.

4. Add edge cases and error states

Ask what can go wrong:

• invalid input
• missing data
• expired links or sessions
• users without permission
• empty states
• duplicate submissions
• slow or unavailable services
• browser, device, or accessibility constraints

Example:

Given the password reset link has expired,
When the user opens the link,
Then they see a clear error message and can request a new link.

5. Make every criterion testable

QA should be able to turn each criterion into a test case. Replace vague words with observable outcomes.

6. Review before sprint planning

Acceptance criteria should be reviewed before estimation. Developers, QA, Product, and design should all understand the same expected result.

If the team cannot estimate the story because the criteria are unclear, the story is not ready.

Given/When/Then Acceptance Criteria Example

Use this format when the story describes user behavior.

Given [starting context],
When [user action or system event],
Then [expected result].

Filled example:

Given a registered shopper has products in the cart,
When they apply a valid discount code,
Then the order total updates with the discount amount.

Given the shopper enters an expired discount code,
When they apply the code,
Then they see a message that the code has expired.

Given the discount code cannot be combined with another offer,
When the shopper applies the code,
Then the system explains which offer is active and why.

This works because each scenario has a clear context, action, and expected result.

Checklist Acceptance Criteria Example

Use checklist format when the ticket needs scannable conditions more than full scenarios.

Acceptance Criteria:
- [ ] User can filter products by category
- [ ] User can filter products by price range
- [ ] Results update within 2 seconds
- [ ] Empty state appears when no products match
- [ ] Filters can be cleared in one action
- [ ] Mobile and desktop layouts are supported

This works well for Jira tickets where Product and QA need a quick shared list.

Rule-Based Acceptance Criteria Example

Use rule-based criteria when the work depends on policy or business logic.

Business Rules:
- Discount codes cannot be combined with automatic promotions
- Expired discount codes cannot be applied
- Discount codes cannot reduce the order total below zero

Acceptance Criteria:
- [ ] Valid discount codes reduce the order total correctly
- [ ] Expired discount codes show a clear error message
- [ ] Incompatible offers explain which discount is active
- [ ] Taxes and shipping are calculated after the correct discount rules

This format makes the rules visible before engineers start implementation.

Acceptance Criteria Review Checklist

Before a story enters sprint planning, check:

• The user or actor is clear
• The expected outcome is specific
• Each criterion can pass or fail
• Happy path is covered
• Error states are covered
• Edge cases and boundary conditions are covered
• Permissions and roles are clear
• Performance, security, or compliance constraints are included if relevant
• Open questions are listed
• Product, Engineering, and QA agree on the criteria

Common Acceptance Criteria Mistakes

Mistake 1: Writing vague outcomes

Weak:

The dashboard should work well.

Better:

The dashboard loads the user's active projects within 2 seconds and shows an empty state when no projects exist.

Mistake 2: Writing implementation details

Weak:

Use Redis cache for project search.

Better:

Search results appear within 500ms for 95% of requests.

Mistake 3: Only covering the happy path

Weak:

User can upload a file.

Better:

- [ ] User can upload a supported file under 10MB
- [ ] Unsupported file types show a clear error
- [ ] Files larger than 10MB are rejected before upload starts
- [ ] Upload progress is visible while the file is uploading

Mistake 4: Writing acceptance criteria after development

Acceptance criteria should guide the build, not document what was already built. Write them during refinement, then adjust only when the team agrees the scope changed.

Acceptance Criteria vs Definition of Done

Use acceptance criteria to define what the story must do. Use Definition of Done to define the team's standard for finished work.

Quick Copy-Paste Acceptance Criteria Template

## Acceptance Criteria

Given [context],
When [action],
Then [expected result].

- [ ] Happy path is testable
- [ ] Error states are covered
- [ ] Edge cases are covered
- [ ] Permission rules are clear
- [ ] Performance, security, or compliance constraints are explicit
- [ ] Open questions are listed

For a fuller reusable version, use the Acceptance Criteria Template. To generate criteria from rough notes, use the Acceptance Criteria Generator.

FAQ

What are acceptance criteria?

Acceptance criteria are the conditions a user story must satisfy before the Product Owner or team can accept it as complete.

How do you write acceptance criteria?

Start with the user story, choose a format, write the happy path, add edge cases and error states, make each item testable, and review the result with Product, Engineering, and QA.

Should acceptance criteria be Given/When/Then or checklist format?

Given/When/Then is best for user behavior, workflows, and BDD-style testing. Checklist format is faster for straightforward Jira tickets. Many teams use both.

How many acceptance criteria should a user story have?

Most user stories need 3 to 7 acceptance criteria. If you need more than 10, the story may be too large and should probably be split.

Who writes acceptance criteria?

The Product Owner usually writes the first draft. Developers, QA, designers, and stakeholders refine them during backlog refinement or sprint planning.

Can acceptance criteria describe implementation details?

Usually no. Acceptance criteria should describe behavior and outcomes, not internal implementation. Technical tasks can explain how the team will build the solution.

What is the difference between acceptance criteria and Definition of Done?

Acceptance criteria are specific to one story. Definition of Done is a team-wide quality checklist that applies to every story or backlog item.