What is Given-When-Then format
Given-When-Then is the standard structure for writing acceptance criteria in agile methodologies. Given describes the initial context or precondition, When specifies the action executed by the user or system, and Then defines the expected observable outcome.
This format eliminates ambiguity by forcing you to think in terms of verifiable behavior. For example: 'Given a logged-in user with admin role, When they access the statistics panel, Then they see metrics from the last 30 days'. Each criterion must be independent, testable, and expressed from the end user's perspective, not the internal code.
Common mistakes: mixing multiple actions in one When, using Then to describe technical implementation ('backend calls API X') instead of observable outcome, or writing overly vague Givens ('user is in the app'). A good criterion should convert directly into an automated test case.
How to structure effective criteria
The quality of a criterion depends on its measurable specificity. Instead of 'Then user sees success message', write 'Then a green toast appears with text "Changes saved" for 3 seconds in the top-right corner'. The more concrete, the less room for divergent interpretations between dev and QA.
Each story should have between 3 and 7 criteria. Fewer than 3 usually indicates the story is too simple or underdefined; more than 7 suggests you should split it into smaller stories. Always include at least one edge case criterion (empty field, no connection, user without permissions) and one happy path.
Use real data in examples: instead of 'When entering invalid email', specify 'When entering "user@domain" without the .com'. This helps the team visualize exactly what to validate. Avoid unnecessary technical jargon: 'modal closes' is better than 'ModalWrapper component executes onClose() method'.
Use cases in agile teams
Acceptance criteria are the shared contract between Product Owner, development, and QA. During refinement, the PO writes initial criteria and the team refines them: dev identifies technical edge cases, QA adds validation scenarios, UX clarifies interface behaviors.
In sprint planning, criteria help with estimation: a story with 4 simple criteria is probably smaller than one with 6 criteria including 'sync with external API'. During development, each commit or PR should reference which criterion it implements. In code review, the checklist is literal: 'are all 5 Then statements fulfilled?'.
For QA, each criterion is a minimum test case. If you have 5 criteria, you generate at least 5 tests (ideally more, adding variations). In the sprint demo, the PO verifies each criterion live before accepting the story. Well-written criteria eliminate the classic 'but I understood something different' in review.
Common mistakes and how to avoid them
Mistake #1 is writing criteria from the system's perspective instead of the user's. 'Given database has 50 records' isn't useful; better 'Given user has 50 products in their catalog'. Criteria should describe what the user perceives, not the system's internal state.
Another common issue: non-atomic criteria. 'When user completes form and clicks Submit' mixes two actions. Separate them: one criterion for real-time validation while completing, another for submit. This allows incremental testing and development.
Avoid ambiguous verbs like 'manage', 'handle', 'process'. 'What exactly does it mean for user to "manage" their preferences?' Be specific: 'When user activates "Email notifications" toggle, Then they receive confirmation email within 5 minutes'. Measurable, testable, clear.
Finally, don't use criteria as a technical task list ('integrate Stripe API', 'create DB table'). That goes in subtasks. Criteria describe user-observable behavior, period.