How to Write Acceptance Criteria That Teams Can Build and Test

Writing acceptance criteria helps product owners, developers, QA testers, and stakeholders agree on what a feature must do before it is accepted as complete.

Good acceptance criteria remove guesswork. They explain the expected behaviour, edge cases, validation rules, and success conditions in a way the team can build and test.

If you need the full definition first, read our guide on what acceptance criteria are. This article focuses on how to write clear, practical acceptance criteria for software projects.

What makes good acceptance criteria?

Good acceptance criteria are clear, testable, realistic, and focused on the user or business outcome.

They should answer one simple question:

What must be true before this feature, requirement, or user story can be accepted?

Weak acceptance criteria leave room for interpretation. Strong acceptance criteria help the team know exactly what to build, what to test, and what to approve.

For example:

Weak:

The dashboard should be fast.

Better:

The dashboard should load the first 50 records within 3 seconds on a standard connection.

The second version is stronger because it can be tested as pass or fail.

How to write acceptance criteria in 7 steps

1. Start with the user goal

Begin with the user story, feature request, or business requirement. Clarify who the user is, what they want to do, and why it matters.

Example:

As a customer, I want to reset my password, so that I can regain access to my account.

This gives the acceptance criteria a clear purpose.

2. Define the successful outcome

Write what should happen when everything works correctly. This is the happy path.

Example:

1. The user can request a password reset using a registered email address.
2. The system sends a reset link to the registered email.
3. The user can create a new password using the reset link.

Start with the main outcome before adding edge cases.

3. Add important business rules

Next, include rules the feature must follow. These may relate to permissions, limits, pricing, status changes, workflows, or compliance.

Example:

1. The reset link expires after 30 minutes.
2. The new password must meet the platform’s password rules.
3. The same reset link cannot be used twice.

Business rules help prevent confusion during development and testing.

4. Include error states and edge cases

Good acceptance criteria should not only cover the ideal scenario. They should also explain what happens when something goes wrong.

Example:

1. If the email address is not registered, the system shows a safe generic message.
2. If the reset link has expired, the user sees an expired link message.
3. If the password does not meet security rules, the system shows a clear validation error.

This helps developers and QA teams handle real user behaviour, not just perfect flows.

5. Make each criterion testable

Every acceptance criterion should be possible to verify as true or false.

Avoid vague words like:

1. Fast
2. Simple
3. Easy
4. User-friendly
5. Secure
6. Reliable

These words are not wrong, but they need measurable detail.

Instead of “the system should be secure,” write:

1. The account is locked for 15 minutes after five failed login attempts.

6. Choose the right format

There are two common acceptance criteria formats: Given/When/Then and checklist format.

Use Given/When/Then when you need to describe user behaviour and system response.

Example:

-Given the user is on the login page

-When they request a password reset with a registered email

-Then the system sends a reset link to that email

Use checklist format when you need to list rules, validations, permissions, or conditions.

Example:

- User can request a reset link.

- Reset link expires after 30 minutes.

- Unregistered emails show a safe generic message.

- User can set a new password that meets security rules.

For deeper guidance on both formats, read our guide on acceptance criteria formats.

7. Review with product, development, and QA

Acceptance criteria should not be written in isolation. Before development starts, review them with the people who will build, test, and approve the work.

A good review should confirm:

1. The requirement is clear.
2. The scope is realistic.
3. The criteria are testable.
4. Edge cases are covered.
5. The team agrees on what “accepted” means.

This step reduces rework and helps teams catch gaps before they become delivery problems.

Acceptance criteria checklist

Use this checklist before moving a user story, feature, or requirement into development.

Good acceptance criteria should be:

1. Clear and easy to understand
2. Written in plain language
3. Focused on user or business outcomes
4. Specific enough to test
5. Free from vague wording
6. Linked to a clear requirement or user story
7. Covering happy paths and error states
8. Including key business rules
9. Including permissions or role-based rules where needed
10. Realistic for the team to build
11. Reviewed by product, development, and QA

Worked example: writing good acceptance criteria

User story:

As a project manager, I want to filter tasks by status, so that I can quickly review progress.

Good acceptance criteria:

Given the project manager is viewing the task list

When they select “Completed”

Then only completed tasks are displayed

Checklist version:

1. Tasks can be filtered by pending, in progress, and completed.
2. Selected filters update the task list immediately.
3. The user can clear the selected filter.
4. If no tasks match the filter, the system shows an empty state.
5. The selected filter remains visible after the list updates.

For more scenarios like this, explore these practical acceptance criteria examples.

Common mistakes to avoid

One common mistake is writing acceptance criteria that are too broad. “Users can manage invoices” does not explain what actions are allowed, who can perform them, or what rules apply.

Another mistake is writing tasks instead of outcomes. “Build the checkout page” is a task. “The user can complete payment and receive a receipt” is acceptance criteria.

Teams also make the mistake of ignoring negative scenarios. A feature is not complete just because the happy path works. Good acceptance criteria should include invalid inputs, missing data, failed payments, access restrictions, empty states, and error messages where relevant.

Finally, avoid turning acceptance criteria into technical instructions too early. Focus on what the system must do, not how developers must implement it.

Need help turning requirements into build-ready software?

Clear acceptance criteria are only one part of successful software delivery. Your team also needs clear product scope, user stories, technical priorities, and a delivery plan that reduces risk before development starts.

At Wazobia Technologies, we help startups and businesses turn ideas, workflows, and requirements into custom software that is clear, testable, and ready to build.

If you are planning a SaaS platform, internal system, automation project, or customer-facing product, explore our software development partnership to see how we can support your team from discovery to delivery.

Final thoughts

Good acceptance criteria help software teams build with clarity and test with confidence. They reduce assumptions, improve planning, and give stakeholders a clear way to approve completed work.

Start with the user goal, define the successful outcome, add business rules, include edge cases, choose the right format, and review everything with the team before development begins.

For the complete topic overview, read our guide on what acceptance criteria are. For more practical examples, explore these acceptance criteria examples.

FAQs

1. How do you write acceptance criteria?

Start with the user goal, define the successful outcome, add business rules, include error states, make each criterion testable, choose the right format, and review with product, development, and QA before work starts.

2. What are good acceptance criteria?

Good acceptance criteria are clear, specific, testable, realistic, and focused on the expected user or business outcome. They should help the team know what to build, test, and approve.

3. What is an acceptance criteria checklist?

An acceptance criteria checklist is a quality check used before development starts. It confirms that the criteria are clear, testable, complete, realistic, and reviewed by the right team members.

4. What format should acceptance criteria use?

The two common formats are Given/When/Then and checklist format. Given/When/Then works well for user behaviour and workflows. Checklist format works well for rules, validations, permissions, and simple conditions.

5. Who should write acceptance criteria?

Acceptance criteria are usually drafted by the product owner, product manager, or business analyst, then reviewed with developers, QA testers, designers, and relevant stakeholders.