pm-user-stories

pm-user-stories — Break an Epic into User Stories

Part of the Personal Corp framework — running a one-person business through AI agents. Decompose a large requirement or Epic into independently-deliverable User Stories. Every Story is validated against INVEST. Output is ready to paste into Jira, Linear, or GitHub Issues.

Inputs

Step 1 — Map the full requirement

Extract from the requirement:

• Roles involved: who uses this? (end user, admin, ops, etc.)
• Core flow: main path? branches?
• Business rules: constraints and conditions?
• Data entities: what data objects are involved?

Step 2 — Pick a splitting pattern

Five patterns. Pick by requirement shape; combine for hybrids.

Selection principle: target ≤ 1 Sprint per Story. Hybrid requirements combine patterns.

Granularity calibration:

• Stories < 3 → likely too coarse; check for hidden sub-flows
• Stories > 20 → likely too fine, or this is multiple Epics; split Epics first
• Single Story estimate > 8 points → too big; split further

Step 3 — Write each User Story + AC

### US-{N}: {Story title — verb-led, e.g. "Choose payment method"}

**Role:** As a {role}
**Action:** I want to {specific action}
**Value:** so that {business value}
**Priority:** P0 (must) / P1 (important) / P2 (nice-to-have)
**Story Points:** {estimate}

**Acceptance Criteria:**
- [ ] Given {precondition}, When {action}, Then {expected result}
- [ ] Given {exception precondition}, When {action}, Then {error handling}

**Dependencies:** {other Story IDs, or "none"}
**Tech notes:** {dev callouts, optional}

Story Point reference (Fibonacci):

AC quality rules — every AC must satisfy:

• Specific: Given clause has a concrete precondition ("user logged in AND balance ≥ 100"), not "user logged in"
• Testable: Then clause has a verifiable result ("balance decreases by 100 AND order status = paid"), not "payment succeeds"
• Edge coverage: every Story has ≥ 1 happy-path AC + ≥ 1 exception-path AC

Step 4 — INVEST validation

Run each Story against the six checks:

Definition of Ready (must hold before entering development):

Dependency rules:

• Data dependency: Story B needs data created by Story A → B depends on A
• Interface dependency: Story B calls API provided by A → B depends on A
• No dependency: Stories on different objects or different roles → parallel
• Pseudo-dependency: looks dependent but mockable → tag "Mockable to decouple"

Step 5 — Output a Story Map

## Epic: {requirement name}

### Story Map (user journey → Story mapping)

| Journey stage | Stories | Priority | Points |
|---|---|---|---|
| {stage 1} | US-001, US-002 | P0 | 5 |
| {stage 2} | US-003, US-004 | P1 | 8 |

### Sprint planning
- **Sprint 1 (MVP):** {Story list}, total {X} points
- **Sprint 2:** {Story list}, total {X} points

### Dependencies
US-001 → US-003 → US-005 (must follow this order)
US-002, US-004 (parallel)

Quality bar

1. Every Story passes all six INVEST checks
2. AC uses Given-When-Then with ≥ 1 happy + ≥ 1 exception
3. Dependencies tagged explicitly, with mockability flagged
4. 13-point Stories must be re-split
5. Story Map includes Sprint planning suggestion

When input is incomplete

• One-sentence requirement → first output a feature outline, confirm scope, then split
• Too large (> 20 Stories) → recommend splitting into Epics; agree on MVP scope first
• Missing business rules → tag [business rule TBD] and propose plausible assumptions for confirmation

Related skills

• /pm-prd — write a PRD first to lock scope, then break into Stories
• /pm-prioritize — when there are many Stories, RICE-rank for Sprint priority