Introduction

Writing clear and well-defined acceptance criteria (AC) is essential for successful product development. AC ensures that all stakeholders—from developers to testers—understand what needs to be built, how it should function, and when it’s considered complete.

In this article, you’ll learn:

  • What acceptance criteria are and why they matter
  • How to write effective acceptance criteria
  • Best practices and common mistakes to avoid

By the end, you’ll have a structured approach to writing AC that improves communication, reduces scope creep, and enhances product quality.

What Are Acceptance Criteria?

Acceptance criteria are a set of predefined conditions a product or feature must meet before it can be accepted as “done.” They define functional requirements, non-functional requirements, and business rules to ensure alignment across development teams.

Why Are Acceptance Criteria Important?

  1. Clarity – Ensures developers and stakeholders share a common understanding of the feature.
  2. Scope Control – Prevents unnecessary feature expansion (scope creep).
  3. Testability – Helps QA teams verify whether a feature works as expected.
  4. User-Centric Focus – Ensures that development aligns with business and user needs.

Types of Acceptance Criteria

There are three main types of acceptance criteria:

  1. Functional Criteria – Defines what the system should do.
    • Example: “Users should be able to reset their password via a verification email.”
  2. Non-Functional Criteria – Covers performance, security, and usability aspects.
    • Example: “The page should load within 2 seconds on a 4G network.”
  3. Business Rules – Ensures compliance with policies or regulations.
    • Example: “Users must be at least 18 years old to register.”

How to Write Effective Acceptance Criteria

Use the Given-When-Then Format 

The Given-When-Then format helps define AC in a structured, testable way.

  • Given [a precondition]

  • When [an action is performed]

  • Then [an expected outcome should occur]

Example:

Given the user is on the login page

When they enter the wrong password three times

Then they should receive a “Forgot Password?” prompt

Keep It Simple and Clear

  • Avoid technical jargon unless necessary.
  • Ensure non-technical stakeholders can easily understand it.
  • Use active voice and direct statements.

Bad Example: “The system should have the ability to allow users to retrieve lost credentials.”

Good Example: “Users should be able to reset their password via email verification.”

Make AC Measurable and Testable

Each acceptance criterion should be quantifiable and verifiable by the QA team.

Vague: “The app should load quickly.”Specific: “The app should load within 2 seconds on a 4G network.”

Prioritize Using the MoSCoW Method

Must have – Essential functionality.

Should have – Important but not critical.

Could have – Nice-to-have but not mandatory.

Won’t have – Features intentionally excluded for now.

Cover Edge Cases and Error Handling

Think about unexpected scenarios that could occur.

Example (Edge Case Handling):

  • Given a user enters an incorrect password 5 times,
  • When they try again,
  • Then they should be locked out for 15 minutes.

Maintain Consistency Across ACs

  • Stick to a single format (e.g., Given-When-Then or bullet points).
  • Keep AC concise (3-5 criteria per feature is ideal).
  • Align AC with user stories for clarity.

Common Mistakes to Avoid

Being Too Vague – “The app should be user-friendly.” (What does this mean?)

Not Considering Negative Scenarios – Ensure you define what should happen if the user enters invalid data.

Overloading AC with Too Much Detail – Complex logic should be in technical documentation, not AC.

Acceptance Criteria in Product Requirements Documents (PRD)

Here’s a PRD outline in which user stories and acceptance criteria appear in the same section. Some people prefer to have a separate section for acceptance criteria, but I find this format easier to follow. 

Document Overview

  • Product Name: [Product/Feature Name]

  • Document Owner: [Owner Name]

  • Version: [Version Number]

  • Date: [Creation/Update Date]

Executive Summary

  • A brief overview of the product or feature and its purpose.

Objectives & Goals

  • What this feature aims to achieve.

  • Business value and impact.

User Stories and Acceptance Criteria 

Each user story should have a corresponding set of acceptance criteria that define the conditions under which the feature is considered complete.

For example: 

User Story:“As a user, I want to reset my password so that I can regain access to my account if I forget it.”

Acceptance Criteria:

  1. Given the user is on the login page, when they click “Forgot Password?” and enter a valid email, then they should receive a password reset link.
  2. Given the user enters an invalid email, when they submit the request, then they should receive an error message: “Email not found.”
  3. Given the user clicks on the password reset link, when they enter a new password and confirm it, then their password should be updated.
  4. Given the user enters mismatched new passwords, when they try to submit, then they should receive an error message: “Passwords do not match.”

Using the “Given-When-Then” format is also not compulsory; you can still define the acceptance criteria without it. 

The rest of the PRD may outline the non-functional requirements, design considerations and summary of changes. 

Looking for a PRD format. Check this out! 

Key Takeaways:

  1. Use Given-When-Then for structured AC.
  2. Keep criteria simple, measurable, and testable.
  3. Prioritize AC using the MoSCoW method.
  4. Cover edge cases and error handling.