story-splitting

What this skill does

# Story Splitting (Vertical Slicing Patterns)

## Overview

A pattern catalog for splitting epics and large stories into smaller, shippable, end-to-end slices that still deliver user value. Built on Richard Lawrence's canonical story-splitting flowchart (the 9 patterns most product teams converge on) with worked before/after examples and a quick-reference decision tree.

The single most common reason teams fail to deliver predictably is that stories are too large. Large stories balloon in cycle time (see `cycle-time-analyzer/`), create coordination overhead, and resist incremental release. The remedy is not to estimate more carefully; it is to split smaller. This skill catalogs the techniques that actually work, in the order to try them, with examples drawn from typical SaaS, mobile, and B2B product scenarios.

The output of using this skill is a set of vertically sliced user stories that each (1) deliver value the end user can perceive, (2) fit in a single sprint, (3) are independently shippable, and (4) pass INVEST quality gates (see `wwas/`). The skill is pattern-based -- no Python tool is needed; the value is the recipes and the worked examples.

### When to Use

- **Sprint refinement** -- A story exceeds the team's 85th-percentile cycle time or fails the INVEST-S (Small) test.
- **Epic decomposition** -- An epic from `create-prd/` or `story-mapping/` needs to be broken into a release backlog.
- **Stuck story** -- A story has been "almost done" for two sprints; usually a sign it should have been split.
- **New team onboarding** -- A team's stories are routinely too large; introduce the patterns explicitly.
- **Release planning** -- Need to find a thin slice that ships in 2 weeks instead of 8.

### When NOT to Use

- The work is a true atomic operation that genuinely cannot be split (rare; usually a sign of incomplete analysis).
- The team is splitting horizontally by layer (DB, API, UI) -- that produces non-shippable slices and defeats the point.
- The work is a spike (timeboxed investigation); spikes are intentionally not user-facing.

## Vertical vs Horizontal Slicing

A common anti-pattern is to split stories by technical layer:

```
Story: Build search.
Split into:
  - Story A: Database schema for search index
  - Story B: API endpoint for search
  - Story C: UI for search results
```

This is **horizontal slicing**. Each slice is not shippable to users, none provides value alone, and you cannot demo any until all three are done.

**Vertical slicing** crosses every layer for a thin slice of functionality:

```
Story: Build search.
Split into:
  - Story A: Search by exact name match (DB + API + UI for one query type)
  - Story B: Search with autocomplete suggestions (extends UI + API + DB)
  - Story C: Search across multiple fields (broadens query type)
```

Each story is independently demoable and releasable. This is the goal.

## The 9 Canonical Splitting Patterns (Lawrence)

Richard Lawrence's 2009-2012 work on story splitting (the "Story Splitting Flowchart") identifies nine patterns that cover the vast majority of real splits. Try them in roughly this order.

### Pattern 1: Workflow Steps

If a story covers a multi-step workflow, split by step. Ship one step at a time.

**Before:** *"As a user, I want to onboard so I can use the product."*

**After:**
1. Confirm email (step 1)
2. Connect data source (step 2)
3. Invite teammates (step 3)
4. Create first dashboard (step 4)

Ship each step alone behind a feature flag or progressive disclosure.

### Pattern 2: Business Rule Variations

If a story embeds multiple business rules, split by rule. Ship the most common rule first.

**Before:** *"As an admin, I want to apply discounts to orders."*

**After:**
1. Flat-percent discount (most common case)
2. Buy-one-get-one
3. Tiered volume discount
4. Coupon-code discount with expiration

### Pattern 3: Happy / Unhappy Path

If a story includes both success and failure handling, split. Ship the happy path first; add unhappy path slices.

**Before:** *"As a user, I want to upload a CSV with full error handling."*

**After:**
1. Upload a valid CSV up to 10 MB (happy path)
2. Reject and explain invalid file types
3. Reject and explain CSVs that exceed size
4. Reject and explain malformed rows with line-numbered errors

### Pattern 4: Input/Output Variations (Interface Options)

If a story supports multiple input methods or output formats, split by variation.

**Before:** *"As a user, I want to export reports."*

**After:**
1. Export to CSV
2. Export to PDF
3. Schedule recurring export to email
4. Export via API

### Pattern 5: Data Variations

If a story handles multiple data types or sources, split.

**Before:** *"As a user, I want to connect a data source."*

**After:**
1. Connect Postgres
2. Connect MySQL
3. Connect Snowflake
4. Upload static CSV file

### Pattern 6: Data Entry Methods

If a story offers multiple ways to enter the same data, split by method.

**Before:** *"As a user, I want to add contacts to my CRM."*

**After:**
1. Manual single-contact entry
2. Bulk paste from spreadsheet
3. Import from CSV
4. Sync from email integration

### Pattern 7: Deferred Performance / Quality

If a story includes both functional behavior and performance/quality requirements, split. Ship working-but-slow first; add a performance slice.

**Before:** *"As a user, I want to load my dashboard in under 1 second."*

**After:**
1. Load my dashboard with any performance (functional baseline)
2. Optimize dashboard load to under 3 seconds (acceptable)
3. Optimize dashboard load to under 1 second (target)

The deferred-quality split is among the most useful and most underused. Most teams confuse "shipping at quality" with "shipping each story at final quality" -- they are not the same thing.

### Pattern 8: Operations (CRUD)

If a story implies multiple operations on the same entity, split by operation. Ship the most-needed operation first.

**Before:** *"As a user, I want to manage my saved searches."*

**After:**
1. View my saved searches (Read)
2. Save a new search (Create)
3. Delete a saved search (Delete)
4. Rename a saved search (Update)

The order is intentional: Read first (no risk of bad data); Create next (now there is data to interact with); Delete before Update (deletes are easier and unblocks user accidents); Update last.

### Pattern 9: Break Out a Spike

If the story carries enough technical uncertainty that the team cannot estimate or split it, the *first* slice is a timeboxed spike (research, prototype, proof-of-concept). The spike's output is enough learning to apply Patterns 1-8 to the rest.

**Before:** *"As a user, I want to authenticate with my company's SSO."*

**After:**
1. **Spike (2 days):** Investigate which SAML libraries we can use, test against our top 3 customer IdPs.
2. Authenticate via Okta (most common customer IdP)
3. Authenticate via Azure AD
4. Authenticate via Google Workspace

Spikes are not user-facing; they exist to enable subsequent vertical slices.

## The Splitting Decision Tree

When a story feels too big, walk this tree top-down. The first pattern that applies is the one to use. Most stories can be split by more than one; pick the one that produces the most usable first slice.

```
Is there enough technical certainty to plan?
  NO  -> Pattern 9 (Spike)
  YES -> continue

Does the story span multiple workflow steps?
  YES -> Pattern 1 (Workflow Steps)
  NO  -> continue

Does the story embed multiple business rules?
  YES -> Pattern 2 (Business Rule Variations)
  NO  -> continue

Does the story include happy + unhappy paths?
  YES -> Pattern 3 (Happy / Unhappy Path)
  NO  -> continue

Does the story support multiple input/output options?
  YES -> Pattern 4 (Input/Output Variations)
  NO  -> continue

Does the story handle multiple data types or sources?
  YES -> Pattern 5 (Data Variations)
  NO  -> continue

Does the story offer multiple entry methods for the same data?
  YES -> Pattern 6 (Data Entry Methods)
  NO  -> conti