The User Acceptance Criteria Builder turns a one-line user story into a set of clear, testable Given-When-Then scenarios. Acceptance criteria are where a story stops being a wish and becomes something a team can build and verify against, so structuring them well prevents the “that is not what I meant” conversations late in a sprint.
How it works
The builder frames your story as a standard “As a [role], I want [action], so that [benefit]” statement, then converts each condition-and-outcome pair you enter into a Given-When-Then scenario. Given states the precondition or context, When states the action the user takes, and Then states the expected, observable result. The tool always seeds a happy-path scenario and prompts you to add edge cases (empty input, limits) and error conditions (invalid data, failures), because criteria that only cover the happy path let real bugs ship.
Tips and example
- One outcome per scenario. If a “Then” needs the word “and” for unrelated results, split it into two scenarios so a failure points at one thing.
- Cover the negatives. Most defects hide in error and edge cases, so always add at least one invalid-input and one boundary scenario.
- Keep it observable. Write “Then” clauses about what the user sees or the system does, not about internal implementation, so the criteria stay valid through refactors.
Example: for “As a shopper, I want to apply a discount code, so that I pay less” — Given an active code, When I apply it at checkout, Then the order total drops by the discount amount plus an error scenario for an expired code.