Foundation
The Story Format
A user story is a promise for a conversation — not a specification. The canonical format is:
As a [type of user], I want [some goal or action], So that [some reason or benefit]. Example: As a returning customer, I want to save my cart between sessions, So that I can complete my purchase later without re-adding items.
Stories are conversation starters. The card is a reminder of the discussion to have — the real value is in the conversation between the team and the customer/PO, not in the written text.
Three Cs
Card → the written reminder (a few sentences) Conversation → discussion between team and PO/customer Confirmation → acceptance criteria that confirm "done"
Foundation
The INVEST Criteria
A well-formed story is INVEST — a checklist for story quality used during backlog refinement.
I
Independent
Can be developed in any order. No hard dependency on other stories.
N
Negotiable
Details can change until committed. Not a contract — a placeholder for a conversation.
V
Valuable
Delivers value to a user or the business. "Technical tasks" that don't create user value should be enablers, not stories.
E
Estimable
The team can size the effort. If not, the story needs clarification or splitting.
S
Small
Completable within one sprint. "Small" is relative to team velocity — typically 1–5 points.
T
Testable
Acceptance criteria can be defined. If you can't test it, you can't know it's done.
Acceptance Criteria
Writing Acceptance Criteria
Acceptance criteria (ACs) are the confirmation conditions that define when a story is Done. They belong on the story before it enters a sprint.
Bullet format (most common)
Story: As a user, I want to reset my password via email. Acceptance criteria: ✓ User can enter their email on the "Forgot password" screen ✓ A reset link is sent to the email address within 60 seconds ✓ The reset link expires after 24 hours ✓ The reset link can only be used once ✓ User sees an error if the email is not registered ✓ Success message is shown after password is changed
Acceptance Criteria
Gherkin / BDD Format
Given-When-Then format (Gherkin) is used when ACs need to drive automated acceptance tests (Cucumber, SpecFlow, etc.).
Feature: Password reset
Scenario: User resets password with valid email
Given I am on the "Forgot password" page
When I enter a registered email address
And I click "Send reset link"
Then I see "Check your email for a reset link"
And a reset email is delivered within 60 seconds
Scenario: User enters unregistered email
Given I am on the "Forgot password" page
When I enter an email not registered in the system
And I click "Send reset link"
Then I see "If this email is registered, you'll receive a link"
And no email is sent
BDD works best when developers, testers, and the PO write scenarios together — not when a BA writes them in isolation.
Story Splitting
Why Split Stories?
Large stories (epics) must be split into deliverable slices before entering a sprint. Vertical slices — end-to-end functional pieces — are almost always better than horizontal layers (front end vs back end).
Bad split: "Backend for checkout" + "Frontend for checkout" → neither delivers value independently.
Good split: "Cash payment at checkout" + "Card payment at checkout" → each delivers value end-to-end.
Good split: "Cash payment at checkout" + "Card payment at checkout" → each delivers value end-to-end.
Story Splitting
8 Splitting Patterns
| Pattern | Description | Example |
|---|---|---|
| By workflow step | Split a multi-step process into individual steps | "User registers" → "Enter details" + "Verify email" + "Complete profile" |
| By business rule | Each rule variation becomes a story | "Apply discount" → "10% for loyalty" + "20% for bulk" + "Free shipping for premium" |
| By happy/unhappy path | Separate success and failure scenarios | "Login" → "Login succeeds" + "Login fails — wrong password" + "Account locked" |
| By user role | Different actors get different stories | "Export data" → "Admin exports all" + "User exports own data" |
| By data variation | Different data types handled separately | "Search" → "Search by name" + "Search by email" + "Search by date" |
| By CRUD | Separate create, read, update, delete | "Manage team" → "View members" + "Add member" + "Remove member" |
| By performance | Basic function first; performance later | "Load dashboard" → "Load data (any speed)" + "Load data (<2s)" |
| Spike first | Research story to reduce uncertainty before implementation | "Integrate Stripe" → "Research Stripe API options (timebox 1 day)" + "Implement chosen approach" |
Hierarchy
Epics, Themes, & Stories
Theme → a broad area of customer value (e.g. "User authentication")
Epic → a large body of work that spans sprints (e.g. "Single sign-on")
Story → deliverable in one sprint (e.g. "Log in with Google")
Task → sub-task within a story (e.g. "Implement OAuth callback")
Rules:
→ Only Stories enter a sprint backlog — not Epics
→ Epics are split before sprint planning
→ Themes are labels, not backlog items
→ Tasks are created by developers during the sprint
Reference
Anti-Patterns
| Anti-Pattern | Problem | Fix |
|---|---|---|
| Stories as tasks | "Implement the API endpoint" — no user, no value | Frame around the user outcome, not the technical task |
| Missing "so that" | Team doesn't understand why; wrong solution risks | Always articulate the user benefit — it shapes the solution |
| No ACs before planning | Team commits without knowing what "done" means | ACs must be agreed before a story enters the sprint |
| Technical stories as first-class | "Refactor database schema" — no user value | Frame as enabler, or fold into a user-facing story |
| Horizontal slicing | Frontend in one sprint, backend in next — neither is shippable | Vertical slices only: each story delivers end-to-end value |
| Story as specification | Multi-page document replaces conversation | 3 sentences + ACs; the rest is conversation |
| Stories written solo | BA writes stories in isolation; team surprised in planning | Refinement is collaborative: PO + team writes together |
| Giant stories ("epics") | Can't be completed in a sprint; velocity lies | Split before the sprint begins; use the 8 splitting patterns |
| Accepting stories without testing them | PO signs off without checking against ACs | ACs are the formal acceptance test; PO must verify each criterion |
Reference
User Story Cheat Sheet
Story format As a [user type], I want [action], so that [benefit]. INVEST checklist I — Independent · N — Negotiable · V — Valuable E — Estimable · S — Small · T — Testable Acceptance criteria formats Bullet list → "✓ User can ... ✓ System shows ..." Gherkin/BDD → Given [context] / When [action] / Then [outcome] Story hierarchy Theme → Epic → Story → Task Top 3 splitting patterns 1. By workflow step (most common) 2. By happy/unhappy path (easy win) 3. By user role (when actors have different needs) Quality checks → Does it deliver value independently? → Are ACs defined before planning? → Can it be completed in one sprint? → Would the team know when it's done?