User Story SplittingSAFE

Product Management skills framework built on battle-tested methods for Claude Code, Cowork, Codex, and AI agents.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: user-story-splitting
argument-hint: "[story or epic to split]"
description: Break a large story or epic into smaller deliverable stories using proven split patterns. Use when backlog items are too big for estimation, sequencing, or independent release.
intent: >-
  Break down large user stories, epics, or features into smaller, independently deliverable stories using systematic splitting patterns. Use this to make work more manageable, reduce risk, enable faster feedback cycles, and maintain flow in agile development. This skill applies to user stories, epics, and any work that's too large to complete in a single sprint.
type: component
theme: pm-artifacts
best_for:
  - "Breaking a story that's too big to estimate or finish in a sprint"
  - "Applying proven split patterns instead of splitting by component"
  - "Keeping each slice independently valuable and releasable"
scenarios:
  - "This story is too big for a sprint and splitting by frontend/backend isn't working"
  - "Our backlog items keep carrying over — I need real split patterns"
estimated_time: "15-25 min"
---


## Purpose
Break down large user stories, epics, or features into smaller, independently deliverable stories using systematic splitting patterns. Use this to make work more manageable, reduce risk, enable faster feedback cycles, and maintain flow in agile development. This skill applies to user stories, epics, and any work that's too large to complete in a single sprint.

This is not arbitrary slicing—it's strategic decomposition that preserves user value while reducing complexity.

## Input

**Works best with:** The story or epic that's too big — paste it as written.
**Also useful:** Why it's too big (can't estimate, can't finish in a sprint, can't release independently) and your team's sizing ceiling.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended `ARGUMENTS:` line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

**Arriving empty-handed? That works too.** The skill asks for the story text, then walks the split patterns against it.

**Example invocation:** `Split this: 'As an admin, I can bulk-import users from CSV, Excel, or our HR system with field mapping and error handling.'`

## Key Concepts

### The Story Splitting Framework
Based on Richard Lawrence and Peter Green's "Humanizing Work Guide to Splitting User Stories," the framework provides 8 systematic patterns for splitting work:

1. **Workflow steps:** Split along sequential steps in a user's journey
2. **Business rule variations:** Split by different rule scenarios (permissions, calculations, etc.)
3. **Data variations:** Split by different data types or inputs
4. **Acceptance criteria complexity:** Split when multiple "When" or "Then" statements exist
5. **Major effort:** Split by technical milestones or implementation phases
6. **External dependencies:** Split along dependency boundaries (APIs, third parties, etc.)
7. **DevOps steps:** Split by deployment or infrastructure requirements
8. **Tiny Acts of Discovery (TADs):** When none of the above apply, use small experiments to unpack unknowns

### Why Split Stories?
- **Faster feedback:** Smaller stories ship sooner, allowing earlier validation
- **Reduced risk:** Less to build = less that can go wrong
- **Better estimation:** Small stories are easier to estimate accurately
- **Maintain flow:** Keeps work moving through the sprint without bottlenecks
- **Testability:** Smaller scope = easier to write and run tests

### Anti-Patterns (What This Is NOT)
- **Not horizontal slicing:** Don't split into "front-end story" and "back-end story" (each story should deliver user value)
- **Not task decomposition:** Stories aren't tasks ("Set up database," "Write API")
- **Not arbitrary chopping:** Don't split "Add user management" into "Add user" and "Management" (meaningless)

### When to Use This
- Story is too large for a single sprint
- Multiple "When" or "Then" statements in acceptance criteria
- Epic needs to be broken down into deliverable increments
- Team can't reach consensus on story size or scope
- Story has multiple personas or workflows bundled together

### When NOT to Use This
- Story is already small and well-scoped (don't over-split)
- Splitting would create dependencies that slow delivery
- The story is a technical task (use engineering task breakdown instead)

---

## Application

### Step 1: Identify the Original Story
Start with the story/epic/feature that needs splitting. Ensure it's written using the user story format (reference `skills/user-story/SKILL.md` or `skills/epic-hypothesis/SKILL.md`).

```markdown
### Original Story:
[Story formatted with use case and acceptance criteria]
```

---

### Step 2: Apply the Splitting Logic

Use `template.md` for the full fill-in structure and output format.

Work through the 8 splitting patterns in order. Stop when you find one that applies.

#### Pattern 1: Workflow Steps
**Ask:** Does this story contain multiple sequential steps?

**Example:**
- Original: "As a user, I want to sign up, verify my email, and complete onboarding"
- Split:
  1. "As a user, I want to sign up with email/password"
  2. "As a user, I want to verify my email via a confirmation link"
  3. "As a user, I want to complete onboarding by answering 3 profile questions"

---

#### Pattern 2: Business Rule Variations
**Ask:** Does this story have different rules for different scenarios?

**Example:**
- Original: "As a user, I want to apply discounts (10% for members, 20% for VIPs, 5% for first-time buyers)"
- Split:
  1. "As a member, I want to apply a 10% discount at checkout"
  2. "As a VIP, I want to apply a 20% discount at checkout"
  3. "As a first-time buyer, I want to apply a 5% discount at checkout"

---

#### Pattern 3: Data Variations
**Ask:** Does this story handle different types of data or inputs?

**Example:**
- Original: "As a user, I want to upload files (images,

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.