Why this matters
Clear acceptance criteria turn fuzzy requests into testable outcomes. As a Business Analyst, you will use acceptance criteria to align stakeholders, guide developers and QA, reduce rework, and decide when a story is truly done.
- Prioritization: define scope precisely to avoid scope creep.
- Handoffs: give developers and QA a shared, testable target.
- UAT readiness: help business users verify value quickly.
Concept explained simply
Acceptance criteria are the conditions that must be true for a user story to be accepted by the product owner. They describe the boundaries (what is in, what is out), expected behavior, and non-functional needs.
Mental model
Think of a user story as a locked door. Acceptance criteria are the key cuts. If all cuts match, the door opens (the story is accepted). If even one cut is missing, the door stays locked.
Useful formats
- Scenario-style (Given–When–Then) for behavior flow.
Given I am on the checkout page When I apply a valid coupon Then the discount is applied to the order total
- Rule-oriented for business rules.
Rule: Coupons cannot stack - Only one coupon can be applied per order - Coupon must be valid at time of purchase
- Checklist for simple, independent conditions.
- Email field validates format
- Password requires 8+ characters
- Lock account after 5 failed attempts
When to use which?
- Use Given–When–Then for flows or state changes.
- Use Rule lists for constraints, calculations, or policies.
- Use Checklists for simple validations or UI must-haves.
Quality principles
- Testable: each criterion can be verified by a clear test.
- Unambiguous: no subjective terms like "fast" or "easy" without metrics.
- Independent: one failing criterion should not make others untestable.
- Complete but minimal: include happy path, key edge/negative cases, and non-functional needs relevant to the story.
Worked examples
Example 1: Login with 2FA
User story: As a user, I want to log in with two-factor authentication so my account stays secure.
Acceptance criteria
Rule: Credentials validation - Email must be a registered account - Password must match stored hash Scenario: Successful login triggers 2FA Given a registered user with 2FA enabled When they enter correct email and password Then a 6-digit one-time code is sent to their configured channel And the login session remains pending until code verification Scenario: Incorrect password Given a registered user When they enter an incorrect password 5 times within 10 minutes Then the account is locked for 15 minutes Non-functional - OTP delivery occurs within 5 seconds for 95% of requests
Example 2: Shopping cart discount
User story: As a shopper, I want to apply a coupon to reduce my total.
Acceptance criteria
Rule: Coupon eligibility - A coupon is valid if current date is within start/end range - One coupon per order; coupons cannot combine Scenario: Valid coupon Given an order subtotal of $100 When a 10% coupon is applied Then the discount is $10 and total is $90 And tax is calculated on the discounted total Scenario: Expired coupon Given the coupon expired yesterday When it is applied Then the user sees "Coupon expired" and the total is unchanged
Example 3: Profile update
User story: As a user, I want to update my profile so my details are current.
Acceptance criteria
Checklist - First name is required; max 50 characters - Phone number must match E.164 format - Save button disabled if no changes detected - Success message shown within 1 second of successful save - Changes persist after page refresh
How to write strong acceptance criteria (step-by-step)
Ask: What should be true when this story is accepted? What will the user see/do?
Capture constraints, calculations, and policies that must hold.
Write a happy path and at least one edge/negative scenario.
Add specific values, messages, and thresholds (e.g., response time < 2s for 95%).
Review with stakeholders, dev, and QA. Trim anything not needed to accept the story.
Quality checklist (use before grooming)
- Each criterion is verifiable (I can write a test for it).
- Includes happy path + at least one edge/negative case.
- Business rules and calculations are explicit.
- Non-functional needs relevant to the story are stated with metrics.
- No subjective terms (e.g., "intuitive", "fast") without definitions.
- Scope boundaries are clear (what is out of scope).
Acceptance criteria vs. Definition of Done
- Acceptance criteria: specific to a story; define behavior and rules.
- Definition of Done: team-wide checklist (code reviewed, tests passed, docs updated).
Exercises
You can take the Quick Test at the bottom of this page. Everyone can take it for free. Progress is saved for logged-in users.
Exercise 1: Write Gherkin criteria
User story: As a traveler, I want to search flights by origin, destination, and date so I can find options.
- Write at least 1 happy path and 2 edge cases in Given–When–Then.
- Include one performance constraint relevant to search.
Exercise 2: Improve vague criteria
Given criteria: "Results should be fast. Show relevant flights. Handle mistakes nicely." Improve these into testable acceptance criteria.
Common mistakes and how to self-check
- Vague adjectives ("fast"): replace with measurable thresholds.
- Skipping negative cases: add at least one invalid input or failure scenario.
- Mixing solution details with outcomes: focus on behavior, not implementation.
- Overloading the story: if criteria feel like multiple features, split the story.
- Ignoring data rules: specify formats, ranges, and rounding for calculations.
Self-check prompt
Can QA write automated/manual tests directly from these criteria? If not, refine.
Practical projects
- Redesign a login story: write criteria for password reset, lockout, and 2FA.
- Checkout taxes: define rules and scenarios for tax on discounted items.
- Search autosuggest: criteria for relevancy, latency, and empty-state behavior.
Mini challenge (10 minutes)
Pick a mobile banking story: "As a customer, I want to view my last 10 transactions." Write 3–5 acceptance criteria covering: empty account, pagination or scrolling, amount format, and latency.
Who this is for
- Business Analysts and Product Analysts shaping requirements
- Product Owners writing or reviewing user stories
- QA Engineers who validate behavior against criteria
Prerequisites
- Basic understanding of user stories
- Familiarity with product scope and stakeholders
Learning path
- Learn user story structure (As a..., I want..., so that...).
- Practice acceptance criteria formats (Given–When–Then, rules, checklist).
- Apply to real features; review with QA and dev.
- Take the Quick Test to confirm understanding.
Next steps
- Use the quality checklist during backlog grooming.
- Run a 15-minute refinement with QA to add edge cases.
- Start a team library of criteria examples for consistency.