How to Create Acceptance Criteria

Acceptance criteria turn a vague request into a shared definition of done. If a user story says what the user wants, acceptance criteria say what must be true before the work can be called complete. That distinction sounds small, but it is the difference between a team shipping something that merely exists and shipping something that behaves the way stakeholders expected.

For teams that work in Agile, Scrum, Kanban, or any iterative delivery model, acceptance criteria are one of the simplest ways to prevent avoidable rework. They reduce ambiguity, surface hidden assumptions, and give product, design, engineering, and QA a single place to align. Done well, they are short, testable, and written in the language of behavior rather than implementation.

What acceptance criteria are

Acceptance criteria are a set of conditions a product increment must satisfy to be accepted by the team, the product owner, or the customer. They define scope boundaries and make expectations observable.

They are not the same as:

• A full requirements document
• Technical design notes
• QA test cases, though they often inform them
• Sprint tasks, though they help generate them

Think of acceptance criteria as the contract for a story. The user story expresses value; the acceptance criteria define the proof that the value has been delivered.

Why they matter

Well-written acceptance criteria help a team in several practical ways:

• They prevent scope creep by clarifying what is inside and outside the request.
• They improve estimates because the team can see the edges of the work.
• They create a shared understanding across roles.
• They make testing easier because expected behavior is explicit.
• They reduce back-and-forth during review because acceptance is measurable.

A story without criteria often leads to one of two problems. Either the team overbuilds to satisfy assumptions that were never stated, or it underbuilds and misses a requirement that everyone silently expected. Acceptance criteria keep both sides honest.

A simple structure to follow

You do not need a complex template to write good acceptance criteria. In most cases, a small set of clearly written statements is enough.

Here is a compact structure you can use:

Part	Purpose	Example
Condition	The trigger or context	When a user submits the form
Behavior	What the system should do	The system validates required fields
Result	What the user sees or gets	An error appears next to missing fields

Many teams write criteria using the Given / When / Then format because it encourages specificity without forcing a rigid style. For example:

• Given a logged-in user with an empty cart
• When the user clicks checkout
• Then the system should prompt the user to add at least one item

You do not need to use Gherkin syntax for every story, but the pattern is useful because it forces you to think in terms of conditions and outcomes.

How to create acceptance criteria step by step

1. Start with the story outcome

Before writing criteria, restate the user story in plain language. Ask what success looks like from the user?s point of view.

Example:

• User story: As a customer, I want to reset my password so that I can regain access to my account.
• Desired outcome: The customer can request a reset, receive a secure link, and choose a new password.

That outcome is the anchor for your criteria. If a criterion does not support it, remove it or move it into another story.

2. Identify the happy path

The happy path is the normal flow when everything goes right. Write the acceptance criteria for that first.

For the password reset story, the happy path might include:

• The user enters a registered email address.
• The system sends a reset link.
• The user opens the link within the valid time window.
• The user enters a new password that meets policy.
• The system confirms the password change.

The happy path gives the team the baseline implementation. It is also the easiest place to catch missing UI states or unclear transitions.

3. Add the important edge cases

After the happy path, cover the failures and constraints that matter most. Do not try to enumerate every possible edge case. Focus on the ones that affect the user experience, security, data integrity, or support burden.

Useful questions:

• What happens if the input is invalid?
• What if the data is missing?
• What if the action is repeated?
• What if the user is unauthorized?
• What if the system is offline or slow?

For password reset, important edge cases might include:

• The email address is not registered.
• The reset link has expired.
• The new password fails policy requirements.
• The user tries to reuse an old password.

These criteria help developers and QA know where the behavior must be strict and where it can be flexible.

4. Make every criterion testable

A criterion should be specific enough that someone can verify whether it passed or failed. If you cannot test it, it is probably too vague.

Weak examples:

• The page should be user friendly.
• The system should respond quickly.
• The password should be secure.

Stronger versions:

• The form displays an inline error when required fields are empty.
• The API returns a response within 2 seconds for 95% of requests under normal load.
• The password must contain at least 12 characters, including one number and one special character.

The best criteria use observable behavior, not subjective language.

5. Keep the wording simple

Acceptance criteria work best when they are short and unambiguous. Use clear verbs and avoid implementation details unless they matter.

Prefer:

• User sees confirmation message
• Button remains disabled until required fields are complete
• System prevents submission with invalid data

Avoid:

• JavaScript validates the form before React state updates
• The endpoint calls the password service before returning
• The component changes CSS classes based on the internal store

Most stakeholders do not need to know how the system works internally. They need to know what they will experience.

Common formats you can use

Different teams prefer different styles. The right format is the one your team actually uses consistently.

Bullet list format

This is the simplest format and often the most practical.

Example:

• User can submit the form only when required fields are filled out.
• System shows an error if the email field is invalid.
• Confirmation appears after successful submission.

Given / When / Then format

This format is useful when you want a tighter behavior definition.

Example:

• Given the user is on the checkout page
• When the user clicks Place Order with an invalid card
• Then the payment is declined and the error is displayed

Rule-based format

This works well for business logic, compliance, and validation-heavy features.

Example:

• Passwords must be at least 12 characters long.
• Passwords must not match the previous three passwords.
• Password reset links expire after 30 minutes.

The format matters less than consistency and clarity.

A practical checklist for good criteria

Use this quick checklist before you move a story into development:

1. The criteria describe user-visible behavior.
2. The criteria are specific enough to test.
3. The criteria cover the happy path.
4. The criteria include important failure cases.
5. The criteria do not mix in unrelated implementation details.
6. The criteria are short enough to read quickly.
7. The team can agree on whether each item passes or fails.

If you can check all seven, the story is probably in good shape.

Example: turning a vague request into criteria

Suppose the request is: ?Add a login warning.? That is too vague to implement well.

A better version is:

• When a user enters an incorrect password three times, the system displays a warning.
• The warning tells the user they have one attempt left before the account is temporarily locked.
• After the fourth failed attempt, the account is locked for 15 minutes.
• The lockout timer is visible on the login screen.

Notice how the story became actionable. The product owner can confirm the behavior, the engineer can build it, and QA can test it without guessing.

Acceptance criteria versus definition of done

These terms are related, but they are not interchangeable.

Acceptance criteria apply to a specific story or feature. They describe what that feature must do.

Definition of done applies more broadly to the team or release process. It describes the quality bar for completed work.

For example:

• Acceptance criteria: The user can export a CSV file with selected columns.
• Definition of done: The feature has tests, code review, documentation updates, and no critical bugs.

A story can meet its acceptance criteria and still fail the broader definition of done if the code is unstable or poorly tested.

Mistakes to avoid

Several mistakes come up repeatedly when teams write acceptance criteria for the first time.

• Writing criteria that are too broad to test
• Burying criteria inside long paragraphs
• Copying technical tasks instead of behavioral expectations
• Forgetting error states and empty states
• Overloading a single story with too many conditions
• Using words like easy, fast, clean, or intuitive without defining them

If a story starts to feel overloaded, split it. A smaller story with crisp acceptance criteria is usually easier to estimate and release.

How to review criteria with your team

The best time to refine acceptance criteria is before development starts. Review them with the people who will build, test, and approve the work.

A useful review flow looks like this:

• Product explains the user value.
• Engineering confirms the scope and technical constraints.
• QA checks that each criterion is testable.
• Design verifies visible states and copy.
• Stakeholders agree on what counts as complete.

This meeting does not need to be long. The goal is not to rewrite the story in a meeting. The goal is to remove ambiguity before it becomes rework.

A quick template you can reuse

You can adapt this template for most stories:

• Given [context]
• When [action]
• Then [expected outcome]
• And [additional expected outcome]
• And [edge condition]

Example:

• Given a signed-in user with admin permissions
• When they open the reports page
• Then they can see the monthly export button
• And the button is disabled if no report data exists
• And a tooltip explains why it is disabled

Final takeaway

Acceptance criteria are not paperwork. They are a practical tool for reducing ambiguity and making delivery predictable. The best criteria are short, specific, testable, and focused on user-visible behavior.

If you want a simple rule to remember, use this: write the smallest set of statements that lets the team know exactly when the story is done. If you can test it, confirm it, and explain it without guessing, it is probably a strong acceptance criterion.