Planning and Slicing¶

The difference between teams that deliver predictably and teams that don't is rarely talent or effort—it's how they break down work. Good slicing creates small, shippable increments that reduce risk, enable fast feedback, and make progress visible. Bad slicing creates large, uncertain chunks that hide risk until it's too late.

This page covers how to plan and slice work effectively: thinking in vertical slices, managing work in progress, defining done, and creating the rhythm that makes delivery predictable.

What Problem This Solves¶

Most delivery problems start with planning problems:

Big batches hide risk. When work is sliced into large chunks, you don't discover problems until late. The two-week task that's "almost done" for another two weeks is a classic symptom.

Horizontal slicing delays value. When you slice by layer (backend first, then frontend, then integration), you don't deliver value until everything is done. Any delay in one layer delays the whole thing.

Unclear scope creates thrash. When requirements are vague, engineers fill the gaps with assumptions. When those assumptions are wrong, you get rework.

No definition of done creates zombies. Work that's "done" but not really done—missing tests, missing docs, not deployed—clogs the system and creates technical debt.

Good planning and slicing prevent all of these. It's the foundation of predictable delivery.

When to Use This Framework¶

Use this framework when:

• Starting any non-trivial feature (more than a day or two of work)
• Kicking off a project or initiative
• Struggling with predictability or missed estimates
• Onboarding team members to how you plan work

Don't use this framework when:

• Work is truly trivial (small bug fixes, copy changes)
• You're in pure exploration mode with no delivery expectation
• Emergency response where process would slow you down

Even small features benefit from thinking about slicing, but the formality can scale down.

Ownership¶

Core Concepts¶

Vertical Slices¶

A vertical slice is a thin piece of functionality that cuts through all layers of the system and delivers user value. It's the opposite of horizontal slicing, where you build layer by layer.

Horizontal slice (avoid):

1. Week 1: Build database schema
2. Week 2: Build API endpoints
3. Week 3: Build frontend
4. Week 4: Integration and testing

The problem: No value is delivered until week 4. If anything slips, everything slips. You can't learn from users until the end.

Vertical slice (prefer):

1. Week 1: Slice A—User can see their recent orders (minimal UI, minimal data)
2. Week 2: Slice B—User can filter orders by date
3. Week 3: Slice C—User can search orders by product name
4. Week 4: Slice D—Pagination for large order histories

Each slice delivers value. Each can be deployed and validated independently. If priorities change after slice B, you've still shipped something useful.

The INVEST Criteria¶

Good slices are:

• Independent: Can be developed and deployed without waiting for other slices
• Negotiable: Details can be discussed and adjusted
• Valuable: Delivers something a user or stakeholder cares about
• Estimable: Small enough to estimate with reasonable confidence
• Small: Can be completed in days, not weeks
• Testable: Has clear acceptance criteria

If a slice fails these criteria, it probably needs more slicing.

Work in Progress (WIP) Limits¶

WIP limits cap how much work can be in progress at once. They seem counterintuitive—wouldn't starting more work mean finishing more work? No. Starting more work means finishing less work, because context switching, coordination overhead, and hidden blockers multiply.

How to set WIP limits:

• Start with (team size) - 1 as your WIP limit for in-progress items
• Observe what happens. If work flows smoothly, you might lower it. If people are idle, you might raise it.
• The goal is flow, not utilization. Some slack is healthy.

What to do when you hit the limit:

• Help someone else finish their work
• Swarm on a blocker
• Do something outside the WIP-limited category (documentation, learning, tech debt)

Definition of Done (DoD)¶

A Definition of Done is the checklist that defines when work is actually complete—not just "code written" but genuinely done. Without a DoD, work accumulates in a "done but not really" state that creates technical debt and delays delivery.

A typical DoD includes:

• Code complete and merged to main
• Automated tests passing (unit, integration as appropriate)
• Code reviewed and approved
• Documentation updated (if applicable)
• Feature flag configured (if applicable)
• Deployed to staging and smoke tested
• Product acceptance confirmed
• Deployed to production (or ready for release)

Your DoD should be explicit and agreed by the team. When someone says "it's done," everyone should know exactly what that means.

The Slicing Process¶

Step 1: Understand the Outcome¶

Before slicing, make sure you understand what you're trying to achieve.

Questions to answer:

• What user problem are we solving?
• How will we know if we've solved it? (Success metrics)
• What are the constraints? (Timeline, technical, business)
• What's explicitly out of scope?

If you can't answer these questions, you're not ready to slice. Go back to problem definition.

Step 2: Map the Solution Space¶

Sketch the full scope of what could be built. Don't commit to building all of it—just understand the territory.

Techniques:

• User story mapping: Walk through the user journey and identify all the steps
• Event storming: Map the domain events and flows
• Wireframe walking: Walk through the UI and identify all the states and interactions

Step 3: Identify the Minimum Viable Slice¶

Find the smallest thing you can build that delivers value and enables learning.

Questions to ask:

• What's the simplest version a user could actually use?
• What could we build in a few days that would let us learn something?
• What's the core without the edge cases?
• If we could only ship one thing, what would it be?

This is your first slice.

Step 4: Sequence Additional Slices¶

Once you have the minimum slice, identify what comes next. Sequence by value and risk.

Prioritization factors:

• User value: What do users need most?
• Learning value: What will help us validate assumptions?
• Risk reduction: What will tell us if we're on the right track?
• Dependencies: What unblocks other work?

You don't need to plan every slice in detail upfront. Plan the next 2-3 slices well; have a rough idea of what follows.

Step 5: Estimate and Commit¶

Estimate each slice and commit to a realistic timeline.

Estimation principles:

• Estimate in relative size (points, t-shirt sizes) rather than time if possible
• Include uncertainty. "3-5 days" is more honest than "4 days"
• Estimates are for planning, not accountability. If a slice takes longer than expected, that's information to improve future estimates, not a failure.
• Track actual vs. estimated to calibrate over time

What Good Looks Like¶

You'll know planning and slicing is working when you observe:

Failure Modes and Mitigations¶

The Mega-Slice¶

Symptom: Slices are still weeks of work. "We can't slice it smaller."

Root cause: Slicing by technical component, not user value. Or, not investing enough effort in the slicing process.

Mitigation: Challenge "can't slice smaller" with "what's the smallest thing a user could use?" Often, there's a simpler first version hiding inside the mega-slice. Consider the "steel thread" approach: the thinnest path through the entire system.

The Infinite Planning Loop¶

Symptom: Slicing takes as long as building. The team plans and replans without starting work.

Root cause: Perfectionism, uncertainty avoidance, or lack of trust that plans can change.

Mitigation: Time-box planning. If you've spent more than a few hours slicing a feature, start building. Learn from doing. Plans will change anyway.

The Estimate Death Spiral¶

Symptom: Every estimate is wrong. Stakeholders stop trusting estimates. Engineers pad estimates defensively.

Root cause: Slices are too big, too vague, or estimates are treated as commitments instead of forecasts.

Mitigation: Slice smaller. Track actuals vs. estimates without blame—use the data to improve, not punish. Communicate estimates as ranges, not points.

The DoD Drift¶

Symptom: "Done" means different things to different people. Work is declared done but then needs more work later.

Root cause: No explicit DoD, or DoD isn't enforced.

Mitigation: Write down the DoD. Review it periodically. When something is declared done that isn't, address it immediately—don't let the standard erode.

The Backlog Black Hole¶

Symptom: The backlog grows forever. Old items never get done. Nobody trusts the backlog.

Root cause: Everything goes in the backlog, nothing comes out.

Mitigation: Regularly prune the backlog. If something has been there for months and hasn't been prioritized, it's probably not important. Archive it. A smaller, curated backlog is more useful than a comprehensive graveyard.

Copy-Paste Artifact: Slicing Session Agenda¶

## Slicing Session

**Feature:** [Name]
**Date:** [Date]
**Attendees:** [Product, Tech Lead, Engineers]
**Duration:** 60-90 minutes

### Pre-work (async, before meeting)

- Product provides: Problem statement, user value, constraints, non-goals
- Engineers review: Technical context, potential approaches

### Agenda

**1. Context Review (10 min)**

- Product walks through the problem and desired outcome
- Questions for clarification

**2. Solution Space Mapping (15 min)**

- What's the full scope of what we _could_ build?
- Sketch the user journey or technical flow

**3. Minimum Viable Slice (20 min)**

- What's the smallest thing we could ship that delivers value?
- Does it meet INVEST criteria?
- What are the acceptance criteria?

**4. Additional Slices (15 min)**

- What comes after the first slice?
- Rough sequencing by value/risk
- Identify dependencies between slices

**5. Estimation (10 min)**

- Estimate the first 2-3 slices
- Identify uncertainties

**6. Commit (5 min)**

- Confirm first slice scope and target
- Assign ownership
- Schedule follow-up if needed

### Output

- [ ] First slice defined with acceptance criteria
- [ ] Rough sequence of subsequent slices
- [ ] Estimates for near-term slices
- [ ] Ownership assigned

Copy-Paste Artifact: Definition of Done Template¶

## Definition of Done

A story/slice is DONE when all of the following are true:

### Code

- [ ] Code is complete and handles known edge cases
- [ ] Code is merged to main branch
- [ ] No unresolved comments from code review

### Testing

- [ ] Unit tests written and passing
- [ ] Integration tests written and passing (where applicable)
- [ ] Manual testing completed against acceptance criteria
- [ ] No known defects in the delivered scope

### Quality

- [ ] Code review approved by at least one other engineer
- [ ] No new linting/static analysis warnings
- [ ] Performance acceptable (no regressions in key metrics)

### Documentation

- [ ] README updated (if applicable)
- [ ] API documentation updated (if applicable)
- [ ] Runbook updated (if operational changes)

### Deployment

- [ ] Deployed to staging environment
- [ ] Smoke tested in staging
- [ ] Feature flag configured (if applicable)
- [ ] Deployed to production OR release-ready

### Acceptance

- [ ] Product has reviewed and accepted
- [ ] Meets acceptance criteria defined in slice

---

_If any item is not applicable, mark it N/A with a brief reason._

Copy-Paste Artifact: Slice Template¶

## Slice: [Name]

**Parent Feature:** [Feature name]
**Owner:** [Engineer name]
**Estimated Size:** [S/M/L or points]

### User Value

[One sentence: what can the user do after this slice ships that they couldn't before?]

### Acceptance Criteria

- [ ] [Specific, testable criterion]
- [ ] [Specific, testable criterion]
- [ ] [Specific, testable criterion]

### Non-Goals (this slice)

- [What's explicitly not included]
- [What's deferred to a later slice]

### Technical Approach

[Brief description of how this will be implemented]

### Dependencies

- [Any blockers or dependencies on other work]

### Open Questions

- [Questions that need answers before/during implementation]

---

**Actual Size:** [Fill in after completion]
**Notes:** [Learnings for future estimates]

Further Reading¶

• User Story Mapping by Jeff Patton – The definitive guide to story mapping and slicing
• Shape Up by Basecamp – An alternative approach to planning and scoping work
• The Goal by Eliyahu Goldratt – The theory of constraints that underlies WIP limits

Related¶

• Working with Product – How slicing fits into product collaboration
• Quality and CI – How slices flow through CI/CD
• Rituals – Planning ceremonies
• Cadence – Sprint and delivery rhythm
• Decision Making – DACI for planning decisions