The Art of Cutting Impossibly Thin
(and Still Delivering Value)
Nov 20, 2025 · A hands-on workshop for product teams
Quick poll
How many of you have worked on a project where scope kept growing and delivery kept slipping?
What's the biggest feature or epic you're currently working on?
Slicing is breaking large features into small, valuable increments delivered quickly. It is not cutting randomly — each slice must deliver coherent value.
Each thin vertical slice must be usable, testable, and feedback-ready.
Iterative vs Incremental
Iterative = repeated cycles for learning. Incremental = additive, each step builds on the last. We want both — thin vertical slices that are complete end-to-end.
🍖
The Carpaccio Test
Think carpaccio — thin, but each slice is complete and valuable on its own.
Would you rather eat half-cooked ingredients, or a small complete dish?
Horizontal ✗ — Technical completeness
Can't go anywhere until everything is finished. No value until all layers land.
Vertical ✓ — Working software incrementally
Transportation value at every stage. Users can actually move forward.
Modern Best Practice = Vertical Slicing
Aligns with Agile · Reduces risk · Enables fast feedback · Allows course correction · Keeps teams unblocked
"Slice vertically to deliver value continuously, not horizontally to deliver everything eventually."
⚡ Reduce Lead Time
Smaller slices move faster through your system. Less WIP, shorter queues, faster time to production.
📦 Deliver Value Incrementally
Not in big batches. Keep It Simple, Ship It! Large batches = high WIP = slow flow.
🎓 Learn Faster
Early feedback and validation from real users — not assumptions. Every slice is a hypothesis you're testing.
🛡️ Reduce Risk
Ship manageable pieces. If something goes wrong, the blast radius is small. Fail small, learn fast.
🌊 Improve Flow & Maintain Momentum
Teams stay productive and unblocked. Continuous delivery keeps everyone moving — and motivated.
| ✗ DIVIDING | ✓ GROWING |
|---|---|
| Start with the full scope | Start with the smallest working version |
| Break it into smaller pieces | Each increment is complete end-to-end |
| Each piece is a fragment — not valuable alone | Each increment delivers value AND feedback |
| Value only delivered when ALL pieces are done | You learn what the next increment should be |
| Feels like progress. Isn't. | The solution grows toward completeness. |
Dividing = Reductionism / Divide and conquer
Before slicing, make sure the base story is worth slicing. The most common failure point is Value.
I
Independent
Deliverable without another slice
N
Negotiable
Details can still be discussed
V
Valuable ⚠️
Most common failure point
E
Estimable
Team can size it
S
Small
Fits comfortably in a sprint
T
Testable
Has clear acceptance criteria
If your base story lacks value, slicing it smaller won't magically create value — you'll just have small, worthless pieces. Garbage in, garbage out. Always ask: "What value does this deliver to users or the business?" If you can't answer clearly, reframe the story first.
Three steps that apply to any story, any size.
If the split feels forced, go back to Step 2 and try a different pattern.
Before slicing, make sure the story is actually sliceable.
Check INVEST — especially Valuable
"Unsplittable" stories are usually tasks or components masquerading as stories. If you start with something that isn't an increment of value, there's no way to slice it smaller and get an increment of value.
If not Valuable → combine first
Combine the non-story with the other pieces it belongs to — together they represent an increment of value. Then slice that.
If too big → proceed to Step 2
Once you have a Valuable starting point, move to the 9 patterns and find the right split.
Common "unsplittable" red flags
None of these are stories. They're tasks hiding inside a bigger story that hasn't been written yet.
Different views of possibly the same problem and solution space — tools, not rules
Build simple end-to-end first, then add middle steps. Begin with the end — get something all the way through the workflow, even if simplified.
Key principle: Begin with the end. Then add middle steps that enrich the flow.
Watch for the word "manage" — it almost always hides multiple operations.
Split into independent stories:
💡 "Manage my account" hides Create, Read, Update, Delete. Each can be its own story. Ask: which operation delivers most value first?
When a story has multiple ways to accomplish the same goal using different rules, split by those rules. Build one rule completely, then add others.
Each variation is a complete implementation. Start with the most common or most valuable rule. Each is independently valuable and testable.
Build for today's simplest data. Don't build for hypothetical future complexity — evolve when you actually need it. YAGNI.
💡 Hardcoded → simple → complex. Build simplest first; add complexity just-in-time. YAGNI = You Aren't Gonna Need It.
When UI complexity exceeds functional complexity. Separate "make it work" from "make it pretty."
Note: Sometimes the fancy UI IS the value — then don't split this way. But validate the concept with simple input first.
When most effort is in the first implementation. Makes dependencies clear without inflated estimates — the infrastructure for the first item is the hard part.
💡 Don't estimate all pieces the same — the first is bigger. Additional card types are incremental once the infrastructure exists.
When a story keeps growing in planning ("what about x?") — STOP. Ask: "What's the simplest version of this?" Find the core and protect it from complexity creep.
Empowerment: You can say "that's a separate story" — and mean it.
Make it work, then make it fast. The slow version teaches you about search logic, user behaviour, and edge cases. Then optimize.
⚠️ CRITICAL: Don't mark stories 'done' if performance is actually in scope — track it explicitly. Applies to all non-functional requirements: performance, security, scale. Know when NOT to use this: payment processing must be secure from day one.
Last resort — use only when implementation is genuinely unknown. Do just enough investigation to answer specific questions, then STOP.
⏱️
Timebox
2–3 days max. Hard stop.
❓
AC = Questions
Acceptance criteria = the specific questions to answer.
📄
Output = Knowledge
A decision or recommendation — not production code.
Remember: You probably know enough to build something — build it, learn from it. Ask: what's the smallest thing we could BUILD to learn?
Find Complexity & Reduce Variations — your Swiss Army knife when you don't know which pattern to apply.
The specific patterns are just applications of this meta-pattern. Spend time here — work through a real example from your backlog.
You've applied a pattern and have candidate slices. Now choose the best split from the options available.
💡 It may take a few tries. Experiment — you'll know the right split when it reveals stories you can safely defer or throw away entirely.
These don't always get a dedicated slide — but they're powerful in the right context.
⚠️ Not every story needs to be sliced. Slicing has real overhead — consider the cost.
1. Consider the cost of slicing vs batching
Every slice carries ceremony: refinement, planning, review, retro. Sometimes coordination overhead exceeds benefits. If a story is already small (1–2 days) and well understood, don't slice just to slice.
2. Assess the value added by slicing in this context
For tightly coupled work where slices genuinely can't ship independently, batch delivery may be more efficient. True MVPs sometimes need to be complete. Ask: what do we actually gain by slicing this?
3. Weigh stakeholder concerns and objections
"We already committed to the full scope" → Slicing is risk reduction, not retreat. | "It's slower overall" → The first slice is slower. The second costs much less. | "Users won't understand" → The slice is complete — it just does less.
Run each candidate slice through this checklist before accepting it.
If any answer is 'no', keep slicing.
Know the failure modes — they're surprisingly common.
10 minutes
Stretch, hydrate, come back ready for the dojo floor.
While you're up — think of one story from your current backlog that might be too big. We'll need it for round 2. 👊
Rules
✓ Each slice must be deployable
✓ Each slice must add value a user can see
✗ No "setup" or "infrastructure" slices
✗ No horizontal splits
🏆 Thinnest valid first slice wins
Good first slice test: Could a user open it, use it, and get something from it — even if it does very little?
Bonus: If your team disagrees on which slice is the MVP — that's the most valuable conversation of the day.
Role-play between PM / EM / Design. Practise responding to the most common objections to slicing — the ones that actually happen in refinement.
Dave Snowden's Cynefin model tells us which splitting strategy to use — before we pick a pattern.
🟢 Obvious
You've done this before. Just build it. If it's too big, find all the stories and do the most valuable ones first.
🔵 Complicated
Knowable with analysis. Find all the stories and do the most valuable and/or most risky ones first.
🟠 Complex ← most product work
Don't enumerate all the stories. Find one or two that provide value and teach you something. Build those. Use what you learn to find the rest.
🔴 Chaotic
Put out the fire. Splitting stories probably isn't important right now — act first, reflect later.
Disordered: You don't know which domain you're in. Identify the domain before splitting — or you'll apply the wrong strategy entirely.
Most product development is complex — not complicated. This distinction matters more than any slicing pattern.
Complicated — sense → analyse → respond
Cause and effect are knowable in advance. Analyse, plan, execute. Traditional project management works here. Engineering problems governed by physical laws.
Complex — probe → sense → respond
Cause and effect are only visible in retrospect. The problem changes as you solve it. You learn about it by doing it. Probe first — enumerate later.
The Retrospective Coherence Trap
Once you know something, it feels like you should have known it all along. This tricks teams into saying "next time we should plan better" — but you couldn't have. The learning only emerged from doing the work.
Open discussion — go round the room, one answer per group per question.
Small, vertical, valuable.