User Stories And Acceptance Criteria

Why this skill matters for Business Analysts

User stories translate stakeholder needs into small, testable slices of value. Clear acceptance criteria remove ambiguity, align teams, speed delivery, and reduce rework. Mastering this skill helps you facilitate refinement, negotiate scope, and ensure what gets built truly solves user problems.

• Unlocks: accurate backlog items, predictable delivery, smoother QA handoff, and measurable outcomes.
• Used in: discovery, backlog refinement, sprint planning, UAT, and release sign-off.

Outcomes you will gain

• Write concise, user-value-focused stories using INVEST.
• Define testable acceptance criteria in Given-When-Then (Gherkin) style.
• Split large stories into vertical slices with clear dependencies.
• Cover edge cases, non-functional needs, and Definition of Done alignment.
• Trace stories back to requirements and metrics.

Who this is for

• Business Analysts and Product Analysts moving into agile teams.
• New Product Owners needing strong story writing and acceptance criteria.
• QA and developers who want to help shape better stories during refinement.

Prerequisites

• Basic understanding of agile ceremonies (refinement, planning, review).
• Familiarity with stakeholder needs and requirements gathering.
• Comfort discussing systems at a feature level (not necessarily coding).

Learning path (roadmap)

1. Start with the user: Define personas, goals, and key journeys. Write a one-line problem statement for each high-value outcome.
2. Write initial stories: Use the template “As a [persona], I want [capability] so that [benefit].” Keep them INVEST-friendly.
3. Add acceptance criteria: Convert examples into Given-When-Then. Make them observable and pass/fail.
4. Split big stories: Slice vertically by workflow step, scenario, or data set. Avoid technical-only slices.
5. Cover edges and non-functionals: Add negative paths, performance, security, and accessibility criteria.
6. Refine with team: Review with dev + QA, confirm DoD alignment, verify dependencies, estimate readiness.
7. Traceability: Link stories to requirements, metrics, or OKRs; ensure change control.

Given [context]
When  [action]
Then  [observable outcome]

Worked examples (3–6)

1) Sign-in with lockout

Story: As a returning customer, I want to sign in so I can access my orders.

Acceptance Criteria
1. Given a registered user with valid credentials
   When they submit the sign-in form
   Then they land on the dashboard within 2 seconds

2. Given three consecutive failed attempts in 10 minutes
   When the user attempts again
   Then the account is locked for 15 minutes and a clear message is shown

3. Given a locked account
   When time lock expires
   Then the user can attempt to sign in again

2) Product filtering by category and price

Story: As a shopper, I want to filter products so I can quickly find relevant items.

Acceptance Criteria
1. Given products exist in multiple categories
   When the user selects "Laptops"
   Then only products tagged "Laptops" are shown

2. Given the user sets a price range $500–$900
   When filters are applied
   Then only items with price within range are visible

3. Given zero results
   When filters are applied
   Then an empty state explains no matches and shows a "Clear filters" option

3) Password reset with token expiry

Story: As a user who forgot my password, I want to reset it so I can regain access.

Acceptance Criteria
1. Given a registered email
   When a reset is requested
   Then an email with a single-use token valid for 30 minutes is sent

2. Given an expired token
   When the user opens the link
   Then a message explains expiry and offers to request a new link

3. Given a new password set
   When it meets policy (12+ chars, 1 number, 1 special)
   Then the password is updated and prior sessions are revoked

4) Bulk CSV import with validation

Story: As an admin, I want to import users from CSV so I can quickly onboard teams.

Acceptance Criteria
1. Given a CSV with valid headers (email, name, role)
   When uploaded
   Then a preview shows row count and sample rows

2. Given invalid rows (e.g., bad emails)
   When validation runs
   Then invalid rows are listed with line numbers and reasons

3. Given the admin confirms import
   When processed
   Then a summary shows created, updated, and failed counts

5) Accessibility acceptance criteria

Story: As a keyboard-only user, I want to navigate the checkout so I can place orders without a mouse.

Acceptance Criteria
1. Given the checkout page loads
   When the user presses Tab / Shift+Tab
   Then focus order follows a logical sequence and is visible

2. Given any form error
   When announced
   Then screen readers read the error message and link focus to the field

3. Performance: First interaction is responsive (<100ms median) for focus changes

Drills and exercises

• Rewrite three implementation tickets into user-value stories (who, what, why).
• For each story, add 3–5 Gherkin acceptance criteria that are observable and pass/fail.
• List two edge cases and one negative path per story.
• Split one large epic into at least four vertical slices.
• Add one performance and one accessibility criterion where relevant.
• Pair with QA to review wording for unambiguous steps and outcomes.

Common mistakes and how to fix them

• Stories without user value: If your story starts with "Build/Implement...", reframe to who-what-why.
• Vague acceptance criteria: Replace "works fast" with measurable thresholds (e.g., p95 < 2s).
• Horizontal splitting: Avoid backend-only or UI-only slices; cut by workflow scenarios.
• Missing negative paths: Add invalid input, permission denied, empty results.
• Overstuffed stories: If more than 8–13 points or spans multiple personas, split.
• DoD vs AC confusion: AC verifies behavior; DoD is team-wide quality gates (tests, code review, docs).
• No traceability: Link stories to requirement IDs and outcomes to metrics.

Mini project: Appointment scheduling

Goal: Define stories and acceptance criteria for a clinic’s appointment scheduling.

1. Identify personas: patient, receptionist, doctor.
2. Draft 4–6 stories (e.g., book, reschedule, cancel, doctor availability).
3. Add acceptance criteria per story, covering success, edge, and negative paths.
4. Include at least one performance and one accessibility criterion.
5. Map dependencies (e.g., availability before booking).
6. Run a mock refinement: ask QA questions and revise wording.

Acceptance Criteria
1. Given a selected doctor and date
   When viewing availability
   Then only free 20-min slots are shown in local time

2. Given no slots exist
   When viewing availability
   Then an empty state suggests the next available date

3. Performance: Slots load within 1.5s (p95) for up to 200 daily slots

Subskills

• Defining User Personas: Identify key users, goals, and pains to anchor story value.
• Writing Clear User Stories: Craft concise who-what-why statements using INVEST.
• Splitting Stories Properly: Slice vertically by scenario, workflow step, or cohort.
• Defining Acceptance Criteria: Make outcomes observable and pass/fail.
• Given When Then Style: Express behavior in a standard, testable format.
• Edge Cases And Negative Scenarios: Cover invalid inputs, timeouts, and permission errors.
• Dependency Identification: Reveal sequencing and parallelizable work.
• Definition Of Done Alignment: Ensure AC fits team quality gates.
• Acceptance Criteria Review With QA: Co-create testable, unambiguous criteria.
• Story Refinement Sessions: Facilitate estimates, risks, and readiness.
• Maintaining Consistent Granularity: Keep stories similar in size for predictability.
• Traceability To Requirements: Link stories to source requirements and metrics.

Next steps

• Practice on one real feature: draft stories, add Gherkin AC, and get peer feedback.
• Introduce a team checklist: INVEST + edge cases + non-functional AC + DoD alignment.
• Track outcomes: did QA find fewer ambiguities? Did cycle time improve?