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

Field	Required	Notes
Requirement description	yes	An Epic or large requirement; can paste a PRD section
Granularity	no	Sprint-level (1-3 days/story) or iteration-level (1-2 weeks); default Sprint
Team composition	no	FE+BE split / full-stack / has mobile — affects per-tier splitting
Estimation system	no	Fibonacci (1/2/3/5/8/13) or T-shirt (S/M/L/XL); default Fibonacci

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.

Pattern	When to use	Example
By workflow step	Requirement is a complete process	Checkout → pick item / address / payment / confirm
By business-rule variant	Same feature with multiple rule sets	Discount → fixed-amount / coupon / points / combined
By CRUD operation	Requirement centers on one data object	Address book → create / edit / delete / set default
By role perspective	Multi-role feature	Order management → user view / merchant processing / ops dashboard
By complexity progression	Feature has simple and full versions	Search → keyword / filters / suggestions / history

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):

Points	Complexity	Effort	Typical scope
1	Trivial	< 0.5 day	Copy change, config tweak, add an event
2	Simple	0.5-1 day	One CRUD operation, form validation
3	Medium	1-2 days	A complete feature point with business logic
5	Complex	2-4 days	Multi-module interaction
8	Big	4-7 days	New system / new flow core module
13	Re-split	> 1 week	Means the Story is too big — must split

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:

Principle	Check	If fails
Independent	Delete this Story — can the others still ship?	Cyclic deps → merge or re-split
Negotiable	Does it describe "what" or "how"?	Strip implementation detail, keep value
Valuable	Will the user perceive value when this ships?	Pure refactor → attach to a user-perceivable feature
Estimable	Can the team agree on points within 5 minutes?	Wide spread = unclear requirement; clarify first
Small	Fits in one Sprint?	Larger → split
Testable	Can QA write test cases directly from the AC?	Add concrete edge values and expected results

Definition of Ready (must hold before entering development):

Check	Standard	If unmet
AC complete	≥ 1 happy + ≥ 1 exception	Fill ACs, then schedule
No blocking deps	All upstream Stories done or mockable	Tag "Blocked", push to a later Sprint
Designs ready	UI Stories have design specs	No designs → tag "Needs design"
Estimation consensus	Spread < 2×	Re-discuss scope until agreed
Business rules confirmed	All [TBD] resolved	Confirm with PM/business, then dev

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