Acceptance criteria should reduce ambiguity, not add ceremony. Plain language is usually enough. Gherkin helps when branching behavior is complex or test automation is strict.
Example 1: plain language criteria
User story: as a returning user, I want to reset my password so I can access my account.
Acceptance criteria:
- Reset email is sent within one minute.
- Reset link expires after 30 minutes.
- User sees confirmation even if email is unknown.
- New password must meet security rules.
- Successful reset returns user to login with success message.
This is clear for most teams and fast to maintain.
Example 2: Gherkin criteria
Feature: password reset
Scenario: valid reset request Given a registered user requests password reset When the user submits a valid email Then the system sends a reset link And the link expires in 30 minutes
Scenario: unknown email Given a user submits an email not in the system When the reset form is submitted Then the system still shows a generic success message
Gherkin is useful when QA automation or compliance needs formal scenarios.
Quick review checklist
Before a story is ready:
- Is desired behavior observable?
- Are edge cases covered?
- Are non-goals explicit?
- Can QA test each criterion without interpretation?
If any answer is no, refine criteria before sprint commitment.
