part nine · slicing & prioritization

Slicing & Prioritization

Which stories in which release, value-driven.

Slicing is the act of choosing the smallest coherent set of stories that, together, change the situation enough to be worth releasing. Prioritization is the act of choosing which slice ships first. Both are PO decisions, made on the story map (Part 2) in front of the trio.

The slicing question

If we ship only this set, will the prediction be checkable?

If yes, the slice is candidate-shippable. If no, more is needed — but not arbitrarily more; only what makes the prediction checkable.

This is what makes slicing different from feature-listing. A feature list says we want all of these. A slice says these together change the situation, and the rest can wait.

The prioritization principle

Stories are prioritized within a slice by what unlocks the rest. Inside the walking skeleton, the order is:

1. The story that makes the data flow exist — the empty pipe.
2. The story that puts the first record through.
3. The story that lets the activity be performed end to end.
4. The stories that handle the first edge cases.
5. The richness — performance tuning, polish, additional states.

A slice that is built in this order is a slice where, at any point, the team has working software that does something the named person can use. A slice built in any other order produces working components that do not connect until the last day.

Value-driven slicing

The corpus pattern: every story carries a value tag, derived from the Feature Brief's V (Volume I Part 4).

Value tag	Meaning
Required for prediction	Without this story, the prediction cannot be checked
Material to V	This story's presence/absence affects V by >10%
Marginal	This story rounds out the experience but does not move V meaningfully
Optional	Nice-to-have, candidate for later release

A slice contains all required-for-prediction stories. It contains some material-to-V stories, prioritized by which moves V earliest. It rarely contains marginal or optional stories — those wait for richness releases.

The slicing conversation

Held by the PO at the end of Epic kickoff (Part 1) and reviewed at story mapping (Part 2). The PO names the slice. The trio reviews. Two questions:

1. Does the slice deliver the prediction? Required-for-prediction stories all in?
2. Does the slice hold together? Does it make sense to ship as one thing?

A slice that doesn't deliver the prediction is unfinished. A slice that doesn't hold together is two slices wearing one name.

Within the slice — sprint shape

A slice is then sequenced into sprints (or whatever cadence the team uses). The order respects the unlocks the rest principle.

Sprint 1 (the skeleton):
  - Story A: data flow exists (the empty pipe)
  - Story B: a record passes through end to end
  - Story C: the named person can perform one full activity

Sprint 2 (the first richness):
  - Story D: most common edge case
  - Story E: error states
  - Story F: the next-most-used path

Sprint 3 (predict-checkable):
  - Story G: instrumentation for the prediction's check
  - Story H: the analytics events
  - Story I: the documentation the CS team needs

Sprint 1 makes something Gal can do once. Sprint 2 makes it survive contact with the messy real world. Sprint 3 makes it possible to run the check.

What slicing is not

• Not "split the story into smaller tasks". Tasks are technical sub-units the developer creates; they are not slices.
• Not breaking by component (frontend / backend / infra). The slice spans every layer.
• Not "MVP minus features". The slice is positively defined — what is in. Not negatively defined as a stripped-down feature.

When slicing is hard

Some Epics resist slicing. Two patterns to recognise.

• The Epic is actually one slice. The work is irreducibly end-to-end. Accept it. Plan the cycle around the larger slice. Be honest with the client and leadership about what one slice means here.
• The Epic is two Epics in disguise. Re-read the Epic kickoff output. Sometimes the activity that was named contains two coherent activities and the slice you can't draw is across both. Split the Epic.

What this volume produces, in one sentence

Volume III turns a prediction into a slice — small enough to fit a release, end-to-end through every Epic, with the stories trios can defend and the technical drawings the on-call can read at 3am.

Back to the volume cover → · Volume IV — Execution →