flpbalada-user-story-fundamentals

name	flpbalada-user-story-fundamentals
description	Capture requirements from user perspective with structured user stories. Use when writing backlog items, defining acceptance criteria, prioritizing features, or communicating requirements between product and development.

User Story Fundamentals - Capturing User-Centered Requirements

A structured framework for capturing product requirements from the user's perspective. User stories help teams understand who needs a feature, what they want to accomplish, and why it matters.

When to Use This Skill

• Writing backlog items
• Defining feature requirements
• Prioritizing development work
• Communicating with development teams
• Breaking down epics into actionable work
• Ensuring user focus in product decisions

User Story Format

THE STANDARD TEMPLATE

"As a [type of user],
 I want [some goal],
 so that [some reason/benefit]."

Components:
┌─────────────────────────────────────────────────────┐
│  WHO: The user persona or role                      │
│  WHAT: The desired functionality or goal            │
│  WHY: The business value or user benefit            │
└─────────────────────────────────────────────────────┘

This format shifts focus from WRITING about requirements
to TALKING about them, with users at the center.

Core Components

WHO - User Persona

Specificity Spectrum:

Generic (avoid):
├── "As a user..."
└── "As a customer..."

Better:
├── "As a first-time visitor..."
├── "As a returning customer..."
├── "As an admin user..."
└── "As a mobile user..."

Best (with job context):
├── "As a marketing manager who needs weekly reports..."
├── "As a parent shopping for school supplies..."
├── "As a developer debugging production issues..."
└── "As a sales rep preparing for a client meeting..."

WHAT - Desired Functionality

Focus on GOALS, not IMPLEMENTATION:

❌ "I want a blue button in the header"
   (prescriptive, limits solutions)

✓ "I want to quickly access my saved items"
   (goal-focused, enables creativity)

❌ "I want a REST API endpoint"
   (technical implementation)

✓ "I want to integrate my data with external tools"
   (user goal, flexible implementation)

WHY - Business Value

The "So That" Connection:

This part explains:
├── What pain it solves
├── What value it creates
├── Why this matters to the user
└── How it connects to business goals

Without "so that":
"As a user, I want to filter search results"
→ Why? What's the actual need?

With "so that":
"As a user, I want to filter search results
 so that I can find relevant items faster
 when browsing large catalogs"
→ Clear value, enables better solutions

INVEST Criteria

QUALITY CHECKLIST FOR USER STORIES

I - Independent
│   Can be developed and delivered separately
│   No tight coupling to other stories
│
N - Negotiable
│   Details open to discussion
│   Not a rigid contract
│
V - Valuable
│   Delivers real value to user or business
│   Not just technical tasks
│
E - Estimable
│   Team can estimate effort
│   Clear enough to size
│
S - Small
│   Fits within single sprint
│   If too big, split it
│
T - Testable
│   Has clear acceptance criteria
│   Can verify when complete

Acceptance Criteria

Definition

ACCEPTANCE CRITERIA (AC)

Purpose: Define what makes the story "done"
Format: Specific, testable conditions

Example Story:
"As a user, I want to reset my password via email
 so that I can regain access if I forget it"

Acceptance Criteria:
□ User can request reset from login page
□ Email sent within 60 seconds of request
□ Reset link expires after 24 hours
□ Link works only once
□ Password must meet security requirements
□ User receives confirmation after successful reset

Writing Good AC

Characteristic	Example
Specific	"Within 60 seconds" not "quickly"
Testable	"Email contains reset link" - can verify
Outcome-focused	"User can access account" not "system sends"
Complete	Covers happy path AND edge cases

Prioritization Framework

RICE Scoring

RICE = (Reach × Impact × Confidence) / Effort

Reach: How many users affected per time period?
       (100 users/month, 1000 users/quarter)

Impact: How much will it move the needle?
        3 = Massive, 2 = High, 1 = Medium, 0.5 = Low, 0.25 = Minimal

Confidence: How sure are we about estimates?
            100% = High, 80% = Medium, 50% = Low

Effort: Person-months of work
        (0.5, 1, 2, 3...)

Higher RICE score = Higher priority

MoSCoW Method

CATEGORIZATION FOR RELEASE PLANNING

MUST Have (Non-negotiable)
├── Critical for release
├── Legal/compliance requirements
└── Core value proposition

SHOULD Have (Important)
├── High value but not critical
├── Workarounds exist
└── Strong user demand

COULD Have (Nice to have)
├── Desired but not necessary
├── Easy wins if time permits
└── Lower user impact

WON'T Have (Not this time)
├── Explicitly out of scope
├── Future consideration
└── Documented for later

Story Splitting Techniques

When to Split

SPLIT IF:
├── Can't complete in one sprint
├── Story points > 13 (or team max)
├── Multiple distinct user values
├── Contains "and" connecting features
└── Too many acceptance criteria

Splitting Methods

1. BY WORKFLOW STEPS
   Original: "User can complete purchase"
   Split:
   ├── User can add items to cart
   ├── User can enter shipping info
   ├── User can enter payment info
   └── User can confirm and place order

2. BY USER TYPE
   Original: "User can view dashboard"
   Split:
   ├── Admin can view full dashboard
   ├── Manager can view team metrics
   └── User can view personal stats

3. BY OPERATIONS (CRUD)
   Original: "User can manage contacts"
   Split:
   ├── User can create contact
   ├── User can view contact details
   ├── User can edit contact
   └── User can delete contact

4. BY DATA VARIATIONS
   Original: "User can import data"
   Split:
   ├── User can import CSV files
   ├── User can import Excel files
   └── User can import from API

5. BY ACCEPTANCE CRITERIA
   Original: "User can search products"
   Split:
   ├── User can basic keyword search
   ├── User can filter by category
   ├── User can sort results
   └── User can save search

Definition of Done vs. Acceptance Criteria

DEFINITION OF DONE (DoD)        ACCEPTANCE CRITERIA (AC)
────────────────────────        ────────────────────────
Universal checklist             Story-specific conditions
Same for all stories            Unique per story
Quality standard                Functional requirements

DoD Examples:                   AC Examples:
□ Code reviewed                 □ User can X
□ Tests written                 □ System does Y
□ Documentation updated         □ Data validates as Z
□ No critical bugs              □ Performance meets N

Story Template

## User Story

**ID:** [PROJ-123] **Title:** [Brief descriptive title]

### Story

As a [specific user type], I want [goal/desire], so that [benefit/value].

### Acceptance Criteria

- [ ] [Specific, testable condition 1]
- [ ] [Specific, testable condition 2]
- [ ] [Specific, testable condition 3]

### Notes

- [Additional context]
- [Technical considerations]
- [Dependencies]

### Attachments

- [Link to designs]
- [Link to research]

### Estimation

- **Story Points:** [X]
- **Priority:** [High/Medium/Low]
- **Sprint:** [Sprint N]

Real-World Examples

E-commerce

Story: Password-less Login

As a returning customer,
I want to login using a magic link sent to my email,
so that I can access my account without remembering passwords.

Acceptance Criteria:
□ User enters email on login page
□ "Send magic link" option available
□ Email received within 30 seconds
□ Link valid for 15 minutes
□ One-click login from email
□ User lands on their dashboard after login
□ Link cannot be reused after login

SaaS Product

Story: Team Invitation

As an account admin,
I want to invite team members via email,
so that I can onboard my team without manual account creation.

Acceptance Criteria:
□ Admin can enter multiple email addresses
□ Invitation email clearly explains next steps
□ Invited user can set their own password
□ Admin can see pending invitations
□ Admin can revoke pending invitations
□ Duplicate email addresses are prevented
□ Admin can set role during invitation

Common Mistakes

ANTI-PATTERNS TO AVOID

❌ Implementation as story
   "Create database table for users"
   → Not user value, technical task

❌ Missing "so that"
   "As a user, I want to search"
   → Why? What problem does this solve?

❌ Too vague
   "As a user, I want a better experience"
   → What specifically? Not actionable

❌ Too large
   "As a user, I want full account management"
   → Multiple features, needs splitting

❌ Solution prescribed
   "As a user, I want a dropdown menu"
   → Describes UI, not user goal

Integration with Other Methods

Method	Combined Use
Theme-Epic-Story	Stories fit within epic hierarchy
Jobs to Be Done	Stories address user jobs
Five Whys	Find root cause behind story need
Hypothesis Tree	Stories as hypotheses to test
Kanban	Stories flow through board stages

Quick Reference

STORY WRITING CHECKLIST

Format:
□ Follows "As a... I want... so that..." format
□ User type is specific and meaningful
□ Goal is user-focused, not technical
□ Benefit clearly stated

Quality (INVEST):
□ Independent - can be built alone
□ Negotiable - details discussable
□ Valuable - delivers real value
□ Estimable - team can size it
□ Small - fits in single sprint
□ Testable - has clear AC

Acceptance Criteria:
□ Specific and measurable
□ Testable (can verify pass/fail)
□ Covers main scenarios
□ Includes edge cases
□ Outcome-focused

Resources

• User Stories Applied - Mike Cohn
• User Story Mapping - Jeff Patton
• Writing Effective User Stories - Scrum Alliance