Story Splitting (Vertical Slicing Patterns)

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 — vertically, so each slice (1) delivers value the end user can perceive, (2) fits in a single sprint, (3) is independently shippable, and (4) passes INVEST quality gates (see wwas/). The skill is pattern-based — no Python tool is needed; the value is the recipes and the worked examples.

Core Capabilities

• 9 canonical Lawrence patterns — workflow steps, business-rule variations, happy/unhappy path, input/output variations, data variations, data-entry methods, deferred performance/quality, CRUD operations, and break-out-a-spike (plus optional "Major Effort First").
• Vertical-slicing decision tree — a top-down tree that names the first applicable pattern for any oversized story.
• Vertical-vs-horizontal discipline — keeps every slice end-to-end and demoable instead of layer-by-layer.
• Ordering & INVEST gating — sequences slices smallest-value-first and verifies each against I-N-V-E-S-T.

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.

Clarify First

Before splitting, confirm these inputs. If any is unknown or vague, ASK — do not assume:

• The original story's user value in one sentence — no clear value means reframe the problem (create-prd/), not split (gates the whole procedure, Step 1)
• What ships next — beta cohort vs general availability (changes which pattern applies: happy-path-only vs full business rules)
• Why it's too big — exceeds cycle time, fails INVEST-S, or has been "almost done" for sprints (points to the first applicable pattern in the decision tree)

Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the artifact.

Quick Start