Writing Estimable User Stories
YAML--- name: writing-estimable-user-stories description: Writes clear, estimable user stories that development teams can confidently size and implement. Use when creating product backlogs, refining requirements, or when planning poker sessions produce wildly different estimates. --- # Writing Estimable User Stories
Before (Vague): As a user, I want better search.
After (Estimable): As a returning customer, I want to filter search results by price range, so that I can find products within my budget without browsing everything.
Acceptance Criteria:
- Given I'm on the search results page
- When I select a price range filter ($0-$50, $50-$100, etc.)
- Then only products in that range are displayed
- And the result count updates to reflect filtered items
Progress:
- Identify specific user persona (not "user" or "admin")
- Define single, clear goal
- Explain business value with "so that" clause
- Write testable acceptance criteria
- Validate with INVEST checklist
- Test team estimation (should converge within 2-3 points)
Core Format: As a [specific user type], I want [single, clear goal], so that [business value].
Acceptance Criteria:
- Given [context/precondition]
- When [action/trigger]
- Then [expected outcome]
INVEST Validation:
| Criterion | Red Flag | Fix |
|---|---|---|
| Independent | Depends on unfinished work | Remove dependencies or make them explicit |
| Negotiable | Specifies technical solution | Focus on what, not how |
| Valuable | Only developers care | Find the user benefit |
| Estimable | Wide planning poker spreads | Clarify scope, split if needed |
| Small | Multiple weeks of work | Break into smaller stories |
| Testable | "Good UX" or subjective measures | Add specific, measurable criteria |
When to ADD More Acceptance Criteria: Add criteria to the same story when scenarios are:
- Same user interaction flow (variations of the same feature)
- Same technical layer (all frontend or all backend)
- Interdependent (one doesn't make sense without the other)
- Deliverable together in a single sprint
When to SPLIT into Separate Stories: Split when scenarios involve:
- Different user personas (customer vs. admin)
- Different workflows (search vs. checkout)
- Different technical layers (frontend filtering vs. backend optimization)
- Independent value (each can ship alone and provide user benefit)
- Estimation spreads > 5 points (too much uncertainty)
Example 1: E-commerce 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 on every purchase.
Acceptance Criteria:
- Given I have at least one saved payment method
- When I reach checkout
- Then I see my saved option pre-selected with last 4 digits
- Given I select saved payment and click "Complete Order"
- Then my order processes without requiring card entry
Example 2: SaaS Dashboard As a team lead, I want to export sprint velocity data as CSV, so that I can include it in my monthly stakeholder reports.
Acceptance Criteria:
- Given I'm viewing the velocity dashboard
- When I click "Export CSV"
- Then a file downloads named "velocity-[YYYY-MM-DD].csv"
- And contains: sprint name, dates, story points completed/committed
Example 3: Technical Story As a mobile app user, I want catalog pages to load in under 2 seconds, so that I can quickly browse products without waiting.
Acceptance Criteria:
- Product catalog loads in under 2 seconds on 4G connection (p95)
- Image size reduced by 60% (average 2MB → 800KB)
- Lighthouse performance score improves from 45 to 85+
User Persona Specificity:
- ✅ "returning customer", "team lead", "billing administrator"
- ❌ "user", "person", "stakeholder"
Vertical Slicing: Slice through all technical layers to deliver user value:
- ❌ "Build user authentication API"
- ✅ "As a new user, I want to sign up with email and password, so that I can access personalized features"
Testable Acceptance Criteria:
- Measurable: "Page loads in under 3 seconds" not "loads quickly"
- Specific: "Price range: $0-$50, $50-$100, $100-$250, $250+"
- Observable: "Red error message appears below the field"
Pre-Sprint Checklist:
- Specific persona identified
- Single, measurable goal
- "So that" clause explaining value
- 3-7 testable acceptance criteria
- All INVEST criteria met
- Team can estimate without research
Missing Business Value:
- ❌ As a user, I want to update my profile picture.
- ✅ As a freelancer, I want to update my profile picture, so that potential clients see my current professional photo and trust my profile.
Technical Stories (No User):
- ❌ Build API endpoints for notification system
- ✅ As a mobile app user, I want to receive push notifications when my order ships, so that I know when to expect delivery.
Too Vague to Estimate:
- ❌ As a user, I want better performance.
- ✅ As a dashboard user, I want the sales report to load in under 3 seconds, so that I can quickly check daily metrics.
Estimation Red Flags:
- 1-2 points spread: Healthy disagreement, quick discussion
- 3-5 points spread: Moderate confusion, needs clarification
- 5-13 points spread: Major misalignment, story needs refinement
- When team says "It depends on...": Story needs refinement before estimation
Success metric: Team reads a story and starts implementing within 15 minutes, confident they understand the scope and acceptance criteria.