Imported from a53ali/ai-dev (skills/manager/story-slicing/SKILL.md). Install upstream with npx skills add a53ali/ai-dev --skill story-slicing. Copyright stays with the author.

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

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:

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.

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:

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

Agent Instructions

When applying this skill, the agent should:

1. Ask for the epic/story text, or fetch it from Jira via MCP
2. Scan the codebase using the patterns in Step 1 to assess real complexity
3. Run the INVEST check on the input to identify what type of split is needed
4. Apply the first applicable splitting pattern(s) from the 9 patterns
5. Evaluate each proposed slice against the Step 4 checklist
6. Output all slices using the Story Output Template, including codebase impact per slice
7. Flag any slices that still seem too large and suggest the next split
8. 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