AI Skill Report Card
Writing Estimable User Stories
Quick Start15 / 15
Use the Connextra format with all three parts:
As a [user type], I want [goal], so that [reason].
Acceptance Criteria:
- Given [context]
- When [action]
- Then [outcome]
Example:
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
- Then only products in that range are displayed
- Given I have active filters applied
- When I click "Clear all filters"
- Then all search results are shown again
Recommendation▾
Remove some redundancy - the INVEST criteria explanation and later pitfalls section overlap significantly
Workflow14 / 15
Story Creation Process
- Identify the real user - Not "the system" or "admin", but an actual person
- Define single, clear goal - What specifically they need to accomplish
- Explain the why - Business value that justifies the work
- Write testable acceptance criteria - Clear success/failure conditions
- Validate with INVEST checklist (see below)
Progress:
- Story uses specific user persona
- Goal is single and actionable
- "So that" clause explains business value
- Acceptance criteria written in Given/When/Then format
- Story passes INVEST criteria
- Team can estimate without additional questions
INVEST Quality Check
- Independent: Can be delivered without waiting for other stories
- Negotiable: Implementation approach is flexible
- Valuable: Provides real benefit to actual users
- Estimable: Team can size it without extensive clarification
- Small: Completable within one sprint
- Testable: Clear pass/fail criteria exist
Recommendation▾
The 'Pre-Sprint Checklist' at the end largely repeats the workflow checklist - consolidate these
Examples18 / 20
Example 1: E-commerce Checkout Input: "Users want faster payments" Output:
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 a saved payment method on file
- When I reach checkout
- Then I see my saved payment option pre-selected
- Given I select my saved payment method
- When I click "Complete Order"
- Then my order processes without requiring card entry
Example 2: SaaS Dashboard Input: "Better reporting needed" Output:
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 with sprint names, story points completed, and dates
- Given the CSV file is opened
- Then data is formatted for spreadsheet import
Recommendation▾
Consider shortening the 'Common Pitfalls' section by focusing only on the most critical anti-patterns
Best Practices
Story Structure:
- Use specific personas, not generic "users"
- One goal per story - split if multiple objectives exist
- Always include the "so that" clause - it prevents misinterpretation
- Write acceptance criteria before sprint planning
Sizing Guidelines:
- Stories should fit in one sprint
- If planning poker produces 2-13 point spread, refine the story
- Use estimation disagreement as a quality signal, not a debate trigger
Common Patterns:
- Slice vertically through features, not by technical layers
- Focus on user behavior, not system architecture
- Include edge cases in acceptance criteria only if critical
Common Pitfalls
Avoid These Story Formats:
- ❌ "As a system, I need..." (systems aren't users)
- ❌ "Build API for notifications" (no user or value)
- ❌ "As a user, I want better search" (too vague)
- ❌ Stories without "so that" clause (missing business value)
Don't Split by Technical Layers:
- ❌ "Build the API" + "Build the UI" + "Write tests"
- ✅ Single story delivering end-to-end user value
Estimation Red Flags:
- Wide point spreads in planning poker indicate unclear stories
- If team needs 15+ minutes to discuss scope, story needs refinement
- "It depends on..." responses mean story lacks specificity
Pre-Sprint Checklist: Use before adding any story to sprint planning:
- Names specific user/persona
- Single, clear objective
- Business value explained
- Acceptance criteria defined
- Small enough for one sprint
- Team can estimate confidently
- Independent from other backlog stories
- Testable with clear success criteria
Remember: The card is an invitation for conversation, not a complete specification. Good stories enable confident estimation and clear implementation.