Acceptance criteria are a set of predefined conditions that define the exact boundaries of a user story. They dictate what must be built for the story to be considered complete and ready for release.

Effective acceptance criteria serve to align the vision of the client and the development team, ensuring everyone knows exactly what behavior the feature must demonstrate. A good set of criteria must be:

• Verifiable & Testable: Each criterion should yield a binary (pass/fail) result, often allowing for automated or manual testing.
• Concise & Unambiguous: Written in plain language that avoids subjective terms like “fast” or “user-friendly” in favor of quantifiable metrics.
• User-Centric: Focus on the outcome delivered to the user rather than the internal technical process to get there.

Common Formats

Criteria are typically documented using standard Agile formats:

1. Given-When-Then (BDD Format): A structured approach often used for functional scenarios.
   • Given some precondition.
   • When an action occurs.
   • Then the expected outcome happens.
2. Rule-Oriented List: A simple checklist of constraints, rules, or system reactions.
3. “It’s done when…”: A declarative list of the specific conditions met once functionality is delivered.

Best Practices

• Keep it to 3–5 items: If a user story requires more than 8 criteria, it is often too complex and should be split into smaller, more manageable stories.
• Define positive and negative paths: Ensure criteria cover both successful scenarios and edge cases (e.g., what happens when a user enters invalid data).
• Include Non-Functional Requirements: Account for aspects like security, accessibility, and performance.