Work World
120,183 views
25 min · 2 min read
7 steps
Advanced

How to write clear acceptance criteria for user stories or tasks

Clear acceptance criteria make user stories testable, reduce rework, and help teams deliver predictable value. This guide walks you through a repeatable process to write concise, verifiable criteria that stakeholders and testers can use. Follow these steps to save time and avoid ambiguity.

Verified by pleasexplain editors
  1. Step 1: Start with the user goal

    State who benefits and why in one sentence: user role, goal, and expected outcome. This anchors criteria to value and prevents scope creep—spend 2–5 minutes per story to write this.

    [Illustration: person thinking, a short user role-goal-outcome sentence on a sticky note]

  2. Step 2: Make acceptance items testable

    Write each criterion as a specific, observable outcome (not implementation). Use measurable terms like numbers, times, or states—for example, "search returns results within 2 seconds". Limit to 3–8 criteria per story to stay focused.

    [Illustration: checkbox list with measured values like 2s, 10 items, 80% accuracy]

  3. Step 3: Use Given-When-Then format

    For behavior-driven clarity, convert scenarios into Given-When-Then lines: Given a condition, When an action occurs, Then expect a result. Keep each scenario to 1–3 sentences for quick acceptance tests.

    [Illustration: three labeled boxes: Given, When, Then with short sentences inside]

  4. Step 4: Include happy and alternate paths

    Cover the main success path plus 1–3 common alternate or error paths (validation, empty states, permission denied). This prevents surprises during QA and usually takes 5–10 minutes per story.

    [Illustration: branching flowchart showing happy path and two error branches]

  5. Step 5: Specify data and environment constraints

    List precise data, authentication, or environment needs (e.g., "user must have role X", "test with dataset of 50 items"). Clear constraints make tests reproducible across environments.

    [Illustration: server icon, database rows labeled 50, role badge icon]

  6. Step 6: Add acceptance criteria to the definition of done

    Ensure criteria are part of the story’s Done checklist and linked to tests or tickets. This ties delivery, review, and automated tests to the same expectations and reduces post-release fixes.

    [Illustration: clipboard with Done checklist and linked test case IDs]

  7. Step 7: Review with team and stakeholders

    Walk through criteria in the next grooming or stand-up, allow 5–10 minutes for feedback, and update accordingly. Early review uncovers assumptions and aligns testers, developers, and product owners.

    [Illustration: small team around a whiteboard reviewing a list of criteria]


  • Use positive language (what it should do) rather than negatives.
  • Prefer one acceptance per sentence to keep tests atomic.
  • Reference existing standards or UI components by name to avoid reinvention.
  • When possible, link criteria to a test case ID or automated test file.
  • Keep criteria visible in the story header so reviewers see them immediately.
  • If uncertain, add a short note labeled "assumption" to revisit during grooming.

  • Avoid vague words like "user-friendly", "fast", or "intuitive" without numeric definition.
  • Do not mix implementation details (exact CSS, framework) into criteria unless required for compliance.
  • Don’t overload a single story with more than 8 acceptance items—split the story instead.
  • Avoid changing acceptance criteria mid-sprint without team consent.

Was this guide helpful?