Acceptance Criteria

Acceptance criteria are the predefined conditions that a software feature, user story, or deliverable must satisfy to be accepted by the product owner, stakeholders, or end users. They define the boundaries of a feature — what "done" looks like in concrete, verifiable terms. Acceptance criteria transform vague requirements like "the search should be fast" into testable statements like "search results must load within 2 seconds for queries returning up to 10,000 results." They serve as a contract between the development team and stakeholders about exactly what will be delivered.

Characteristics of effective acceptance criteria:

• •Specific: Clear enough that two people would agree on whether the criterion is met
• •Measurable: Can be objectively verified through testing — not based on subjective judgment
• •Achievable: Technically feasible within the constraints of the project
• •Relevant: Directly related to the user story or feature they belong to
• •Testable: Can be translated into one or more test cases for verification

Common formats for acceptance criteria:

• •Given-When-Then (BDD style):
• •Given [context/precondition]
• •When [action is performed]
• •Then [expected outcome]
• •Example: "Given a logged-in user with items in their cart, When they click Checkout, Then they should be directed to the payment page with the correct total displayed"

• •Checklist/Rule-based:
• •The form must validate email format before submission
• •Error messages must appear within 500ms
• •The feature must work in Chrome, Firefox, and Safari
• •Passwords must be at least 8 characters with one uppercase and one number

• •Scenario-based:
• •Describe specific usage scenarios that must work correctly
• •Include both positive (happy path) and negative (error handling) scenarios

The role of acceptance criteria in testing:

Acceptance criteria are the primary source for deriving test cases. Each criterion should map to at least one test case that verifies it. When testers write test cases from acceptance criteria, they provide a direct link between what was requested, what was tested, and whether it passed — this is the foundation of requirements traceability. During test execution, testers use acceptance criteria as the benchmark for pass/fail decisions. During UAT, stakeholders verify the system against acceptance criteria before giving sign-off.

Common mistakes with acceptance criteria:

The most prevalent error is writing acceptance criteria that are too vague. "The system should be user-friendly" or "Performance should be acceptable" are not acceptance criteria — they're wishes. Without specificity, developers don't know what to build, testers don't know what to verify, and stakeholders will inevitably be disappointed because their mental model of "user-friendly" differs from everyone else's. Another common mistake is writing acceptance criteria after development is complete, turning them into a retroactive justification for what was built rather than a specification for what should be built. Acceptance criteria must be defined and agreed upon before development begins. Teams also frequently write acceptance criteria that only cover the happy path, ignoring error handling, edge cases, and non-functional requirements.

Best practices:

• •Define acceptance criteria during refinement/planning, not after development
• •Write criteria collaboratively — involve the product owner, developer, and tester (the "Three Amigos")
• •Include both functional criteria (what the feature does) and non-functional criteria (performance, accessibility, security)
• •Keep criteria independent — each criterion should be verifiable on its own
• •Limit to 5-10 criteria per user story — too many suggests the story is too large and should be split
• •Use acceptance criteria as the definition of done for the story — if all criteria pass, the story is complete