write-acceptance-criteria

Acceptance criteria are best written by enforcing discovery to identify actors and scope, extracting business rules, and structuring them into Given/When/Then scenarios. This ensures criteria are unambiguous and testable across unit, integration, and e2e levels.

Capturing edge cases requires systematic rules extraction to identify business constraints and permissions. These rules are then documented as Given/When/Then scenarios, explicitly covering validation errors, permission checks, and concurrency to ensure unambiguous testable criteria.

Structuring acceptance criteria with Given/When/Then involves writing scenarios for each business rule. You map happy paths, validation errors, and edge cases to test levels, producing a standardized document that aligns product, dev, and QA teams before development.

Non-functional criteria are needed to define performance, accessibility, security, and resilience constraints. They are mapped to appropriate test levels like unit, integration, or e2e, ensuring the user story meets all system requirements and producing a complete acceptance criteria document.

Yes, Example Mapping supports backlog refinement by extracting rules and discovering scenarios, which naturally aligns with an INVEST-style review. This workflow enforces scope identification and surfaces open questions, ensuring backlog items are testable and well-defined.