Why this matters
Clear, testable acceptance criteria (AC) help BAs and QA prevent rework, reduce bugs, and keep releases predictable. In real projects you will:
- Run story kickoffs ("three amigos": BA, QA, Dev) to validate AC.
- Translate business rules into testable behavior.
- Catch edge cases early (errors, limits, non-functional needs).
- Align AC with test cases, preventing gaps and surprises later.
Concept explained simply
Acceptance criteria are the rules that must be true for a story to be accepted. QA uses them to write tests; developers use them to build; product uses them to agree on scope. If AC are precise and testable, delivery speeds up. If they are vague, everything slows down.
Mental model: the contract and the flashlight
Think of AC as a small contract for the story. The BA and QA hold a flashlight over that contract to reveal dark corners: errors, boundaries, and assumptions. If the contract is clear and the corners are lit, work moves smoothly.
Review flow with QA (simple steps)
- Prepare: Draft AC using a clear structure (e.g., Given–When–Then). Note data, constraints, and out-of-scope items.
- Joint review: Walk through each AC with QA. Ask: Is it testable? Are there boundaries, errors, and alternative flows?
- Expand scenarios: Add missing negative/edge cases, performance/UX notes if relevant.
- Trace: Ensure each AC maps to at least one test (and vice versa).
- Agree Definition of Ready: Story only enters development when AC are unambiguous, testable, and cover critical paths.
Quality checklist for acceptance criteria
- [ ] Clear actor and trigger (who does what, when)
- [ ] Observable outcome (what the system must show/return/store)
- [ ] Testable phrasing (no vague words: "fast", "appropriate", "intuitive")
- [ ] Positive, negative, and boundary cases
- [ ] Data rules (formats, ranges, required/optional fields)
- [ ] Error handling and messages (what, when, how shown)
- [ ] Non-functional needs if relevant (e.g., response time target, accessibility)
- [ ] Traceability to tests (each AC will become one-or-more test cases)
Useful formats
- Given–When–Then (GWT) for behavior: Given context, When action, Then observable result.
- Rule + Example for business rules: State the rule, then show concrete examples.
- Decision table for complex combinations (e.g., discounts by role, region, and date).
Worked examples (BA + QA)
Example 1: Login errors
Story: As a user, I want to log in so I can access my dashboard.
Initial AC (problematic):
- AC1: Login should be quick and easy.
- AC2: Show error if login fails.
QA feedback: "Quick and easy" is subjective; which errors? how displayed? rate limiting?
Improved AC:
- AC1 (GWT): Given a registered user with valid credentials, When they submit the login form, Then they are redirected to the dashboard within 3 seconds and a session is created.
- AC2 (GWT): Given an unregistered email or wrong password, When they submit, Then an inline error "Email or password is incorrect" appears and no session is created.
- AC3 (Boundary): After 5 failed attempts within 10 minutes, Then show "Too many attempts" and block login for 10 minutes.
Example 2: Amount field validation
Story: As a user, I want to transfer money between my accounts.
Initial AC (problematic):
- AC1: User can enter an amount.
- AC2: System should validate the amount.
QA feedback: What range? decimals? currency? error copy?
Improved AC:
- AC1: Amount must be between 1.00 and 10,000.00 inclusive; 2 decimal places max.
- AC2 (GWT): Given an amount with more than 2 decimals, When user submits, Then show "Use 2 decimal places or fewer" and keep the value.
- AC3 (GWT): Given an amount above 10,000.00, When submit, Then show "Maximum is 10,000.00".
- AC4 (GWT): Given an amount below 1.00, When submit, Then show "Minimum is 1.00".
Example 3: Search suggestions performance
Story: As a shopper, I want search suggestions as I type.
Initial AC (problematic):
- AC1: Suggestions should be fast.
QA feedback: Define "fast" and behavior for no results, network lag.
Improved AC:
- AC1: Given user types 3+ characters, When typing pauses for 300ms, Then show up to 10 suggestions.
- AC2: 95% of responses return within 400ms (from typing pause to list rendered).
- AC3: If no results, show "No suggestions" placeholder.
- AC4: On network error, show "Try again" and allow retry without clearing input.
Exercises you can do now
These mirror the graded exercises below. Do them here first; then submit your answers in the exercise section.
- Exercise 1 — Make AC testable
Rewrite vague criteria into GWT with clear outcomes. Tip: replace subjective words with measurable conditions. - Exercise 2 — Map AC to tests
For each AC, write at least one positive, one negative, and one boundary test. Add any missing AC you discover.
Self-check checklist
- [ ] Each AC is either GWT or a clear rule with examples.
- [ ] You included at least one negative and one boundary case.
- [ ] Error messages are explicit and consistent.
- [ ] Data rules (formats, ranges) are specified.
- [ ] Non-functional constraints are stated when relevant.
Common mistakes and how to self-check
- Vague language ("fast", "intuitive"): Replace with measurable numbers or specific behaviors.
- Missing error paths: Ask "What could go wrong?" for each field and step.
- Ignoring boundaries: Add min/max values, empty states, timeouts.
- Mixing multiple outcomes in one AC: Keep AC atomic; one outcome per criterion.
- No traceability: Ensure each AC maps to at least one test; if a test exists without AC, add/clarify AC.
Quick self-review ritual (3 minutes)
- Underline every verb and adjective; replace squishy words.
- Add one negative and one boundary case.
- Point each AC to a test ID (even a placeholder).
Practical projects
- Three Amigos rehearsal: Pick one real or sample story. Draft AC, then simulate a BA–QA review. Record changes you made.
- Decision table: For a discount rule with role (Member/Guest) x region (US/EU) x date (Promo/Normal), create a table and translate each row into AC.
- Traceability mini-matrix: Build a small table Story AC ↔ Test Cases. Ensure 1-to-1 or 1-to-many coverage with no gaps.
Who this is for
- Business Analysts who collaborate daily with QA and developers.
- Product Owners seeking tighter alignment with testing.
- QA professionals who want stronger upstream quality.
Prerequisites
- Basic understanding of user stories and acceptance criteria.
- Comfort with simple testing concepts (positive, negative, boundary).
- Familiarity with Given–When–Then is helpful but not required.
Learning path
- Refresh the basics of clear AC (INVEST, GWT).
- Practice BA–QA review using the checklist above.
- Create decision tables for complex rules.
- Map AC to test cases and fill gaps.
- Take the quick test and revisit weak spots.
Mini challenge
Draft AC for: "As a user, I want to reset my password via email." Include: success, invalid token, expired token, rate limiting, and content of confirmation message. Keep AC atomic and testable.
Need a nudge?
- What starts the flow? How is the link generated and validated?
- What does the user see for each failure mode?
- What limits prevent abuse?
Next steps
- Apply the checklist to two existing stories in your backlog.
- Schedule a 15-minute AC review with QA for your next story.
- When you feel ready, take the Quick Test below. Everyone can take it; logging in saves your progress.