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 <outcome>

**Definition of Done check:**
- [ ] Unit tests pass
- [ ] Integration tests pass
- [ ] Acceptance criteria verified
- [ ] No regressions in <related area>
- [ ] Documentation updated (if user-facing)

**Size estimate:** <XS / S / M — if M, consider splitting further>
**Dependencies:** <none / blocked by Story X>
**INVEST score:** I✅ N✅ V✅ E✅ S✅ T✅

Jira Intelligence Commands

This skill pairs with jira-intelligence — a standalone skill with 7 agent-native commands that replicate Jira Premium AI features without a license:

Command	Trigger
Work Breakdown	"Break this epic into stories"
Story Enhancement	"Improve this ticket / rewrite this story"
Comment Summary	"Summarize this ticket / TLDR this thread"
Edge Case Generator	"What are the edge cases for this story?"
Dependency Detector	"Find dependencies / which stories are blocking each other?"
Story Point Estimator	"Estimate this story"
NL → JQL	"Turn this into JQL"

Invoke jira-intelligence directly for any of the above. When slicing a full epic, this skill chains into jira-intelligence automatically for work breakdown and point estimation.

Anti-Patterns Reference

Anti-pattern	Problem	Fix
Layer split (UI / API / DB as separate stories)	Nothing ships until all layers done	Use workflow or happy-path split instead
"Include all edge cases"	Story is actually 3 stories	Happy path first, edge cases follow
Technical task as story	"Create the DB schema" delivers no user value	Embed in a real story or use a spike
Mega spike	"Research the whole feature" — no clear output	Cap at 2 days, define the written output
Split by team member	"Alice does frontend, Bob does backend"	Pair or mob; don't slice by person
Premature performance NFR	"Returns in < 200ms" baked into functional story	Defer performance as a follow-on story

Agent Instructions

When applying this skill, the agent should:

Ask for the epic/story text, or fetch it from Jira via MCP
Scan the codebase using the patterns in Step 1 to assess real complexity
Run the INVEST check on the input to identify what type of split is needed
Apply the first applicable splitting pattern(s) from the 9 patterns
Evaluate each proposed slice against the Step 4 checklist
Output all slices using the Story Output Template, including codebase impact per slice
Flag any slices that still seem too large and suggest the next split
If MCP is available, create the child stories in Jira under the parent epic

References

Richard Lawrence & Peter Green: The Humanizing Work Guide to Splitting User Stories
NextAgile: Vertical Slicing and Horizontal Slicing
Bill Wake: INVEST in Good Stories
Mike Cohn: User Stories Applied
Martin Fowler: Feature Branch — on shipping small increments safely
LeadDev: Breaking down work for faster delivery

story-slicing

SKILL.mdskills/manager/story-slicing/SKILL.md