story-slicing

Story Slicing

Context

Large stories and epics are the #1 cause of missed sprint commitments, deferred feedback, and integration risk. The fix is not to "try harder" — it's to slice differently. Most teams slice horizontally by technical layer (UI story, API story, DB story) — a glorified waterfall that produces nothing shippable until all layers are done. Vertical slicing cuts end-to-end through all layers, delivering a thin but complete and usable increment after every sprint.

This skill combines:

• Richard Lawrence's 9 story splitting patterns — the most widely used framework in agile coaching
• INVEST criteria — the acceptance test for every slice
• Codebase analysis — grounds sizing in real complexity, not guesses
• Jira MCP — creates child stories directly from the analysis

---

Vertical vs Horizontal Slicing

	Horizontal (❌ avoid)	Vertical (✅ target)
How it slices	By technical layer or skill	End-to-end through all layers
Example	"Design story", "Backend story", "QA story"	"User can log in with email/password (happy path)"
Demo-able at sprint end?	No — each slice is incomplete alone	Yes — working feature, even if limited
User feedback possible?	No	Yes
INVEST-compliant?	No (not Valuable, not Independent)	Yes
Risk	Integration crunch at end	Caught early

The sandwich analogy (nextagile.ai): Horizontal = separating the bun, lettuce, patty, tomato into layers. Vertical = cutting the whole sandwich into smaller sandwiches — each one complete and edible.

---

Step 1 — Codebase Analysis (Agent-Driven)

Before slicing on paper, analyze the codebase to understand the real cost of each slice.

What to scan

Service/module boundaries:

# Understand the architecture
find . -name "*.service.*" -o -name "*.controller.*" -o -name "*.handler.*" | head -30
find . -name "routes.*" -o -name "router.*" | head -20
ls src/ services/ modules/ packages/ apps/ 2>/dev/null

API surface (how many endpoints does this feature touch?):

grep -rn "@Get\|@Post\|@Put\|@Delete\|@Patch\|router\.\(get\|post\|put\|delete\)" src/ --include="*.ts" --include="*.js" | grep -i "<feature_keyword>"

Schema / migration impact:

ls db/migrations/ migrations/ prisma/migrations/ 2>/dev/null | tail -10
grep -rn "ALTER TABLE\|CREATE TABLE\|addColumn\|createTable" migrations/ db/ 2>/dev/null

Test coverage surface:

find . -name "*.test.*" -o -name "*.spec.*" | xargs grep -l "<feature_keyword>" 2>/dev/null

Cross-cutting concerns (auth, logging, feature flags):

grep -rn "featureFlag\|isEnabled\|authorize\|@Guard\|middleware" src/ --include="*.ts" | grep -i "<feature_keyword>"

Complexity signals

Use the scan to estimate the slice's real cost:

Signal	Low complexity	High complexity
Services touched	1	3+
New API endpoints	0–1	3+
Schema changes	None	New table / multi-column
Auth/permission changes	None	New role or scope
New test files needed	1–2	5+
Cross-service calls	None	Sync or async integration
Feature flag needed	No	Yes (phased rollout)

Key insight: A story that touches 3 services, adds 4 endpoints, and requires a schema migration is almost certainly 2–3 sprints of work. Slice it before estimation, not during.

---

Step 2 — INVEST Check on the Input Story

Before splitting, evaluate whether the input story/epic fails INVEST — this tells you what kind of split is needed.

INVEST	Check	Failure → Split by
Independent	Can this be built without waiting for another story?	Workflow steps or spike first
Negotiable	Are details still open?	That's fine — don't over-specify
Valuable	Does this deliver user-perceivable value alone?	Role or happy-path split
Estimable	Can the team give a rough size?	Spike story needed first
Small	Fits in ≤ half a sprint?	Apply splitting patterns below
Testable	Do we know what "done" looks like?	Acceptance criteria split

---

Step 3 — Richard Lawrence's 9 Splitting Patterns

Apply these in order. Use the first pattern that produces independently valuable stories.

Pattern 1 — Workflow Steps

Split by the sequential steps a user takes through a workflow.

Original: "As a user, I can manage my account"
→ S1: User can update their profile photo
→ S2: User can update personal information
→ S3: User can change their password
→ S4: User can delete their account

✅ Best for: Large features with a clear user journey. Each step is usable independently.

---

Pattern 2 — Happy Path / Alternate Paths

Implement the happy path first, then error cases and edge cases as follow-on stories.

Original: "User can log in with email and password"
→ S1: User can log in with valid credentials (happy path)
→ S2: System shows error for invalid credentials
→ S3: System validates email format
→ S4: System validates password complexity
→ S5: System supports 500 concurrent logins within 3s (performance story)

✅ Best for: Any story with multiple acceptance criteria — especially validation, error handling, and performance. Most reliable pattern.

---

Pattern 3 — CRUD Operations

Split by Create, Read, Update, Delete — each is independently valuable.

Original: "User can manage products in the catalogue"
→ S1: User can view the product catalogue (Read)
→ S2: User can add a new product (Create)
→ S3: User can edit a product's details (Update)
→ S4: User can archive a product (Delete/soft-delete)

✅ Best for: Admin panels, dashboards, data management features.

---

Pattern 4 — Data Types / Complexity

Build for the simplest data case first, then add complex variants.

Original: "User can send messages to other users"
→ S1: User can send a plain text message
→ S2: User can send a message with an image attachment
→ S3: User can send a message with a file attachment
→ S4: User can send a message with inline code formatting

✅ Best for: File uploads, rich content editors, multi-format APIs.

---

Pattern 5 — Business Rules

Each distinct business rule becomes a story.

Original: "Apply discount at checkout"
→ S1: 10% discount applied for loyalty members
→ S2: Promo code discount applied at checkout
→ S3: Bulk discount applied for orders over $500
→ S4: Stacked discounts follow precedence rules

✅ Best for: Pricing engines, approval workflows, compliance rules.

---

Pattern 6 — Roles / User Types

Implement for the primary user role first, then extend to other roles.

Original: "Users can view the analytics dashboard"
→ S1: Viewer role can see their own team's analytics
→ S2: Manager role can see all teams' analytics
→ S3: Admin role can export analytics to CSV

✅ Best for: RBAC features, multi-tenant products, permission systems.

---

Pattern 7 — Platform / Interface Variations

Ship on one surface first, then extend.

Original: "Users can complete checkout"
→ S1: Checkout works on web (desktop)
→ S2: Checkout is responsive on mobile web
→ S3: Checkout available as native mobile app flow

✅ Best for: Multi-platform products. Don't wait for all platforms before shipping any.

---

Pattern 8 — Defer Performance / Quality Constraints

Implement correctness first; meet performance/SLA targets as a follow-on story.

Original: "Search returns results in < 200ms"
→ S1: Search returns correct results (no SLA)
→ S2: Search results return in < 200ms under load (performance spike + optimization)

✅ Best for: Any story mixing functional and non-functional requirements. NFRs should be explicit stories, not hidden acceptance criteria.

---

Pattern 9 — Spike (Investigation Story)

When the team can't estimate because of unknowns, create a time-boxed spike first.

Original: "Integrate with Stripe for payments" (team has never used Stripe)
→ Spike: Investigate Stripe integration — auth flow, webhook setup, test mode — 2-day timebox
  → Outcome: ADR + estimated stories for the real implementation
→ S1–SN: (defined after spike)

✅ Best for: New technology, third-party integrations, uncertain architecture. Spikes are not features — cap them at 2 days, and always produce a written output.

---

Step 4 — Evaluate Each Slice

Run every proposed slice through this checklist before accepting it:

□ Independent — can be built and released without another story being done first
□ Valuable — a real user or stakeholder benefits; it's not "just the backend"
□ Demo-able at sprint end — can be shown working in a sprint review
□ Testable — acceptance criteria are written (Given/When/Then)
□ Sized ≤ half a sprint — a team of 2 could finish it in 2–3 days
□ No horizontal layer split — not "Frontend only" or "API only"
□ Happy path is separate from error paths (if large enough to warrant it)
□ Performance / NFR constraints are a separate story (if non-trivial)

Red flags — reslice if any are true:

• "We can't demo this until the other story is done" → dependency, recombine or reorder
• "This is just the API, the UI is next sprint" → horizontal slice
• "This covers all the edge cases" → split off error paths and edge cases
• "This is the whole feature" → almost certainly too big

---

Story Output Template

For each slice, produce:

## Story: <title>

**As a** <role>
**I want** <action>
**So that** <value>

**Why this slice:** <which splitting pattern was applied and why>

**Codebase impact (from analysis):**
- Services touched: <list>
- New endpoints: <list or none>
- Schema changes: <list or none>
- Cross-cutting: <auth changes, feature flags, etc.>
- Estimated test files: <N>

**Acceptance Criteria:**
- [ ] Given <context>, When <action>, Then <outcome>
- [ ] Given <context>, When <action>, Then 

---

*Content truncated.*