A step-by-step guide to creating acceptance criteria that work

It’s a fact of developer life: sometimes new features flop. Maybe it was buggy after launch. Or perhaps the team built something that was technically brilliant but left users confused. It happens to the best of us — but what if we told you there was a near-foolproof way to avoid it? 

Acceptance criteria solves this problem by giving teams a crystal-clear definition of “done”. 

For developers, it’s a guide to building the right functionality. For testers, it’s a checklist for validation. And for managers or product owners, it means critical items don’t fall by the wayside. It’s essential for anyone involved in product design, so let’s take a closer look! 

What does acceptance criteria mean in software development?

Acceptance criteria are basically a to-do list. It contains every condition a product needs to meet before it’s considered “done”. It’s created and signed off by the client and/or product owner and typically covers the following areas: 

• Form
• Functionality
• Performance; and/or
• Compliance with design standards. 

Acceptance criteria helps everyone involved in a project — from developers to testers, product owners, and stakeholders — know what needs to be built, and how it should run. 

What makes good acceptance criteria?

Good acceptance criteria are clear, specific, and testable. They should leave no room for confusion. 

For example:

1. Given a user is logged in, when they click the “Save” button, then their changes should be saved and visible on the dashboard.

This format is known as the “Given-When-Then” structure. “Given” describes the state of things before you (or the user) has begun an action. “When” refers to the action you’re specifying, and “then” describes the changes you expect once the action has taken place. It’s a handy trio that helps to break down conditions in a logical way. 

What’s the difference between acceptance criteria and a user story?

The user story is a description of a feature from the POV of the end user. It explains what the user needs and why. This helps the team understand what they’re doing, and why. 

Classic user story format:

• As a [type of user], I want [an action] so that I can [achieve a goal].

For example:

• As a user, I want to log in so I can access my account.

Key differences

• User story:
  • Describes what the user needs.
  • Focuses on the “why” and “what”.
  • Broad and high-level.

• Acceptance criteria:
  • Describes how the user story will work.
  • Focuses on the “how” and “what happens”.
  • Specific and detailed.

Essentially, the user story describes the goal, and the acceptance criteria sets out the path to achieving that goal. They’re two sides of the product development coin. 

Why do you need acceptance criteria? 

We get it. More processes and paperwork can be a pain. Creating acceptance criteria takes a little work upfront, but it really is a time-saver down the line. 

1. Defines “done” clearly

Product development is hectic. Without acceptance criteria in place, it’s hard to know when a feature is genuinely “done”. Having a pre-defined checklist stops unfinished things slipping through the net before launch. 

2. Aligns team expectations

Dev teams include a range of roles, from developers and designers, to testers, product managers, and beyond. And all of these people have different priorities. Acceptance criteria helps everyone interpret the user story in the same way. It cuts out guesswork and lowers miscommunication.

3. Stops scope creep

Scope creep happens when features balloon beyond their original plan. And it’s very easily done. 

Acceptance criteria keeps the team focused on what’s necessary, stopping unnecessary changes or extra work that wasn’t agreed upon. It also means if there’s a mismatch in expectations between client and the team (which shouldn’t happen with acceptance criteria in place, but it’s not a guarantee), then you have the deliverables in writing and signed off.

4. Guides testing

Testers use acceptance criteria to verify if the feature behaves as intended. It makes testing faster and more accurate, as testers know exactly what to check. Developers can also use it to write automated tests.

5. Improves user satisfaction

When acceptance criteria are clear and well-written, the final product is more likely to meet user needs. This leads to fewer issues and better feedback from users or clients.

6. Saves time and cost

Clear criteria reduce back-and-forth discussions and rework. The team knows what to deliver from the start, which saves time and avoids expensive mistakes.

Real-life example

Imagine building a “Search” feature. Without acceptance criteria, developers might create a basic search box that only works with exact matches. But if the criteria specify that users should see suggestions as they type, the feature will meet the user’s expectations.

Who’s responsible for the acceptance criteria?

Writing acceptance criteria is usually a shared job. The main responsibility falls to a few key roles, but others can add input to make sure the criteria are clear and useful.

Product owner

Most of the time, the product owner takes the lead. They know the user’s needs and the goals of the product. They usually write the first draft of the acceptance criteria, with plenty of input from the client. Their goal is to guide the team by setting clear-as-water expectations.

Scrum master

The scrum master might step in to help refine the criteria, especially if the team needs extra support. They ultimately need to ensure the team has a shared understanding of the work. While they don’t always write the criteria, they make sure the process is smooth and collaborative.

Development team

Developers play a starring role. They review the criteria to check if the requirements are clear and realistic. They can suggest changes to make sure the criteria match what’s technically possible.

Testers or QA engineers

Testers or QA engineers check that the criteria are actually testable. Their feedback is crucial for making sure features are verifiable before launch. 

A team effort

While the product owner is often in charge, acceptance criteria benefit from input across the team. When everyone contributes, the job becomes more practical and precise.

How to write acceptance criteria

Writing good acceptance criteria takes a bit of planning upfront, but it’s a relatively straightforward process in the grand scheme of things. Here’s a step-by-step guide for creating clear, testable criteria your team and clients can count on. 

1. Start with the user story

Every acceptance criteria is tied to a user story. Start by understanding the story. What does the user need? Why does it matter?

Example user story:

• As a user, I want to reset my password so I can log in if I forget it.

Once you know the goal, you’re ready to write criteria that make sure it’s met.

2. Keep the user in mind

Write the criteria from the user’s point of view. This ensures the feature focuses on solving the user’s problem. Avoid writing about how the feature is built — focus on how it should behave.

For example:

• Good: When the user enters their email, they receive a password reset link.
• Not-so-good: The system sends a POST request to the server.

3. Use the “given-when-then” format

This format is simple and works well for most criteria. It breaks the requirement into clear steps:

• Given: The starting condition.
• When: The action the user takes.
• Then: The expected result.

Example

• Given a user enters their email in the “Forgot Password” form,
• When they click the “Submit” button,
• Then they receive an email with a reset link within 1 minute.

4. Be specific

Ambiguous criteria cause confusion. Be as clear and specific as possible. Describe exactly what should happen. For example:

• Vague: The system should send a confirmation.
• Specific: The user should receive a confirmation email with the subject “Order confirmed” and a list of their purchased items.

5. Make it testable

Every acceptance criterion should be something testers or QA can check. Ask yourself: Can this be tested? If the answer is no, rewrite it.

For instance, instead of saying, “The system should be fast”, say, “The page must load in under 3 seconds on a standard connection.”

Make sure your data is quantifiable, independent (i.e., it can be tested in isolation, which avoids dependencies), and has a clear yes/no determination. 

6. Include edge cases

Think about what might go wrong. Cover all possible scenarios, including errors or invalid inputs. This ensures the team knows how the system should behave in unusual situations.

Examples of edge cases:

• What happens if the user enters the wrong email?
• What if the password reset link expires?

7. Use simple, clear language

Avoid technical terms or jargon unless necessary. The goal is for everyone on the team — developers, testers, product owners — to understand it without extra explanation.

For example:

• Instead of saying API timeout, say The page should show an error message if it takes longer than 10 seconds to load.

8. Get feedback from the team

Once you’ve drafted the criteria, share it with the team. Developers, testers, and the product owner can spot gaps or suggest improvements. This ensures the criteria are solid and cover all bases.

Incorporate User Acceptance Testing (UAT) criteria alongside the dev team’s criteria. This gives you insight into how well the feature or app meets usability needs. 

9. Revise as needed

Sometimes, new details come up during development or testing. Be open to refining the criteria to match updated goals or discoveries. Just make sure everyone agrees on the proposed changes.

Acceptance criteria checklist

• ✅ Is it tied to a user story?
• ✅ Does it focus on the user’s needs?
• ✅ Is it written in “Given-When-Then” format?
• ✅ Is it clear and specific?
• ✅ Can it be tested?
• ✅ Does it cover edge cases?
• ✅ Is it easy to read and understand?

Tips on how to create top-tier acceptance criteria

Great acceptance criteria leave no room for confusion. Here’s how to do it right. 

Clear and specific

The criteria should focus on what the feature must do. Avoid vague words like “user-friendly” or “fast.” Instead, say exactly what you mean. For example, instead of saying, “The landing page loads fast,” say, “The page must load in under 2.5 seconds.”

Testable

Good acceptance criteria can always be tested. Ask, “Does the feature work as described?” and verify with a yes or no answer. If the team can’t measure or check it, it shouldn’t make the cut. 

Written from the user’s point of view

Good acceptance criteria keep the user in mind. For each point, describe how the feature needs to perform in the end user’s hands (and not just how it’s built). E.g.: “When the user enters their email and password, they should be logged in and taken to their profile page.”

Simple language

Use short sentences and banish jargon. Everyone on the team should be able to read and understand acceptance criteria, even if they don’t have a techy background. 

Covers edge cases

An amazing criteria also handles “what if” situations. What happens if the user enters the wrong password? What if the network fails? Addressing these cases upfront helps avoid surprises later.

Examples of amazing acceptance criteria

Here’s how a strong acceptance criterion might look.

Example 1: Login feature

• Given a user enters a correct email and password,
• When they click the “Login” button,
• Then they are taken to their dashboard within 2 seconds.
• Given a user enters an incorrect email or password,
• When they click the “Login” button,
• Then they see an error message: “Invalid email or password.”

Example 2: Adding items to a shopping cart

• Given a user is browsing a product page,
• When they click the “Add to Cart” button,
• Then the item is added to their cart and the cart count updates.
• Given an item is out of stock,
• When the user clicks “Add to Cart,”
• Then they see an error message: “This item is out of stock.”

Example 3: Password reset feature

• Given a user enters their registered email in the “Forgot Password” form,
• When they click the “Submit” button,
• Then they receive an email with a password reset link within 1 minute.
• Given a user clicks an expired reset link,
• When they try to reset their password,
• Then they see an error message: “This link has expired. Please request a new one.”

Project management software simplifies the acceptance criteria process

When it comes to product development, the more joined-up everyone is, the better. 

Enter: project management software. These tools help teams stay organized by keeping user stories, tasks, and criteria in one easy-to-access place. Everyone can see what needs to be done and track progress. Teams can add, edit, or update acceptance criteria quickly, helping everyone move as one. 

With Backlog, our own tool, you can link criteria to specific tasks, so nothing gets missed off. Plus, because it’s cloud-based and updated in real-time, team members can leave notes or feedback to clarify any questions, and get instantly notified. This keeps the project running smoothly and everyone up to date.