🎯 Learning Objectives
By the end of this lesson, you will:
- Identify the three parts of a well-formed User Story
- Define what makes an Acceptance Criterion (AC) good or bad
- Apply the INVEST principle to evaluate story quality
- Spot the most common AC red flags
📝 What Is a User Story?
A User Story is the most common format for describing product features in Agile teams. It's written from the perspective of the person using the feature.
The Standard Format:
As a [type of user], I want to [perform some action], so that [I achieve some benefit/goal].
Example:
As a registered user, I want to reset my password via email, so that I can regain access to my account if I forget my credentials.
Each part matters:
- Role — who is doing this? Be specific.
- Action — what exactly are they doing? Be concrete.
- Benefit — why do they want it? This reveals intent and helps with edge cases.
🚩 User Story Red Flags
Watch for these when reviewing:
| Red flag | Problem | Better |
|---|---|---|
| "As a user..." | Too vague — which user? | "As a registered user...", "As an admin..." |
| No "so that" clause | Purpose is unclear | Add the business reason |
| Multiple actions in one story | Too big, hard to test | Split into separate stories |
| Technical implementation details | Story should be what, not how | Remove or move to Tech Spec |
✅ What Are Acceptance Criteria?
Acceptance Criteria (AC) define the specific conditions that must be true for a story to be considered done. They're the contract between the product team and the development team.
Good AC must be:
- Binary — either passes or fails, no "sort of done"
- Specific — describes exact behavior
- Testable — a QA can write a test case from it
- Focused — one condition per criterion
Good AC example:
- Given the user is logged in, when they click "Reset Password", then they receive an email within 60 seconds.
- Given the user enters an email not in the system, when they submit the reset form, then they see: "If this email is registered, you will receive a reset link."
- Given the reset link is older than 24 hours, when the user clicks it, then they see: "This link has expired. Please request a new one."
Bad AC example:
- The password reset feature should work correctly.
- The email should be sent.
- Error messages should be displayed as appropriate.
🔍 What's wrong: "Work correctly", "be sent", "as appropriate" — none of these are testable. You can't write a pass/fail test for any of them.
🔎 The Given/When/Then Format
Many teams write AC using the Gherkin format:
Given [some precondition] When [some action happens] Then [some observable outcome]
This format forces specificity. If you can't complete all three parts, the AC isn't ready.
📐 The INVEST Principle
INVEST is a checklist for evaluating story quality:
| Letter | Meaning | Check |
|---|---|---|
| I | Independent | Can it be built/tested without other stories? |
| N | Negotiable | Is the implementation flexible, not prescribed? |
| V | Valuable | Does it deliver value to someone? |
| E | Estimable | Can the team estimate it? |
| S | Small | Can it be done in one sprint? |
| T | Testable | Can QA verify it's done? |
The T is your domain. If you can't write a test from the story, it fails T — flag it.
🌍 Real-World Review Scenario
Story:
As a user, I want to log in to the application.
AC:
- The login should work.
- Users should be able to enter their credentials.
Your review comments:
- The story doesn't specify which users — registered? social login? admin?
- "Should work" is not testable. What does "working" look like?
- Missing scenarios in AC: wrong password, account locked, empty fields, remember me.
- Missing the "so that" clause — what business value does login provide?
Revised story:
As a registered user, I want to log in with email and password, so that I can access my personal account and saved data.
Revised AC (partial):
- Given valid credentials, when the user submits the form, then they are redirected to the dashboard.
- Given an incorrect password (up to 5 attempts), when submitted, the user sees: "Incorrect email or password."
- Given 5 failed login attempts, when the 6th attempt is made, the account is locked and the user sees: "Your account has been temporarily locked."
💡 Pro Tips
💡 Tip 1: When you see "should work correctly" in AC, replace it with: "what does correct look like?" That question alone is worth its weight in gold.
💡 Tip 2: Count the number of AC on a story. Less than 2? Probably incomplete. More than 8? Probably should be split.
💡 Tip 3: Always check AC for the negative path. If every AC is a happy path, you've found the gap.
📋 Summary
- User Stories have 3 parts: role, action, benefit — all must be specific
- Acceptance Criteria are the contract for "done" — they must be binary and testable
- Use the Given/When/Then format to write unambiguous AC
- Apply INVEST to evaluate story quality
- Common red flags: vague "as a user", missing AC, untestable AC, only happy-path AC
Up next: the sneaky problem of contradictions — when different parts of the same document disagree.