Writing Agile User Stories
Writing Estimable User Stories
Use the Connextra format:
As a [specific user type], I want [specific goal], so that [clear reason].
Acceptance Criteria:
Given [context]
When [action]
Then [expected result]
Example:
As a returning customer, I want to complete my order using my saved payment method, so that I don't have to re-enter my card details every purchase.
Acceptance Criteria:
Given I'm logged in with saved payment methods
When I proceed to checkout
Then I can select from my saved payment options
Given I select a saved payment method
When I click "Complete Order"
Then my order processes without requiring card re-entry
Story Creation Process:
- Identify the real user - Name a specific person/persona, never "the system"
- Define one clear goal - Single, behavioral objective
- Explain the value - Why this matters (the "so that" clause)
- Write acceptance criteria - Use Given/When/Then format
- Apply INVEST check - Verify against all six criteria
- Size validation - Can the team estimate without extensive discussion?
INVEST Checklist:
Progress:
- [ ] Independent: Can be delivered without waiting for other stories
- [ ] Negotiable: Implementation approach is flexible
- [ ] Valuable: Delivers real benefit to actual users
- [ ] Estimable: Team can size without dozens of clarifying questions
- [ ] Small: Completable within one sprint
- [ ] Testable: Clear pass/fail criteria
Example 1: E-commerce Filter ❌ Bad: "As a user, I want better search." ✅ Good: "As a budget-conscious shopper, I want to filter search results by price range, so that I can find products within my budget without scrolling through everything."
Example 2: Dashboard Export ❌ Bad: "As an admin, I want better reports." ✅ Good: "As a team lead, I want to export sprint velocity data as CSV, so that I can include it in my monthly stakeholder report."
Example 3: Notifications ❌ Bad: "Build a notification API." ✅ Good: "As a mobile app user, I want to receive a push notification when my order ships, so that I know when to expect delivery."
Story Quality Indicators:
- Poker planning estimates cluster within 1-2 points
- Team asks fewer than 3 clarifying questions
- Acceptance criteria write themselves naturally
- Story fits on a single index card (if physical)
Effective Acceptance Criteria:
- Cover the happy path clearly
- Include 1-2 key edge cases
- Avoid over-specifying implementation details
- Focus on user-observable behavior
Story Sizing Guidelines:
- Can be demo'd to stakeholders in one sitting
- Touches only one area of the system
- Delivers vertical slice of functionality
- Takes 1-3 days to complete
The Big Five Mistakes:
- Epic Disguised as Story - If poker estimates range from 8 to 21, split it
- Fake Users - "As a system" or "As a stakeholder" aren't real people
- Missing 'So That' - Without the reason, developers fill gaps with assumptions
- Technical Layer Splitting - "Build API" + "Build UI" are tasks, not stories
- No Acceptance Criteria - Story cards are conversation starters, not finished specs
Red Flags During Planning:
- Wide estimate variance (2 vs 13 points)
- Team asks "What does this actually mean?"
- Multiple interpretations emerge during discussion
- Developer says "This could be anything"
When Estimates Vary Widely:
- Don't force consensus - use it as a refinement trigger
- Send story back to product owner with specific questions
- Treat disagreement as story quality signal, not estimation problem
- Schedule dedicated refinement session
Use estimate variance as a story quality detector, not a debate to resolve in the moment.