What is Roadmap slicing?
Cutting a direction into small, reviewable pieces of work. Execution-time slicing cuts each piece only when the previous one has landed.
Slices cut in advance go stale as the code moves; slices cut at execution time see the current code.
On this page
Roadmap slicing is the practice of cutting a direction of work into small, reviewable pieces — and, in the execution-time form, cutting each piece only after the previous one has landed. The slice, not the direction, is the unit that gets built and reviewed; the quality of the slicing decides whether the direction compounds or thrashes.
Two slicing strategies exist, and the difference between them is where most roadmap failures live:
- Big-design-first slicing: the whole direction is decomposed into tasks up front, then executed. The plan is confident; the code it assumed has usually moved by mid-execution.
- Execution-time slicing: only the next slice is cut, against the code as it is now — including everything the previous slices just changed. Each slice is a bet sized to survive contact with reality.
The second is what the term usually means in agent-driven development, and the reason is mechanical: a slice cut against week-old code is a brief with false premises, and an agent executing false premises produces confident work that review must then unwind.
Why slices must be small
The slice size is a trade between coordination cost and feedback cost, and agent-driven work moves the optimum sharply toward small:
| Slice size | What improves | What degrades |
|---|---|---|
| Large (weeks of work) | Less planning overhead | Review exceeds attention; defects compound before anyone looks; a rejection wastes the whole slice |
| Small (a reviewable unit) | Every slice lands verified; feedback steers the next cut | More briefs to write — cheap when the platform derives them |
The units that work are shaped like good tickets: one coherent outcome, acceptance criteria that can be checked mechanically, small enough that review can actually read the diff. A slice that fails those tests is not a slice — it is the direction wearing a smaller name.
What execution-time slicing looks like
The loop has four beats, and the fourth is the one big-design-first skips:
- Look at the direction's goal and what has already landed. The landed slices are facts now; the code they changed is the ground truth.
- Cut the next slice against that ground truth. What is the smallest piece that moves the direction and can be verified on its own?
- Build and review it through the normal pipeline — ticket, implementation, review, QA, delivery.
- Re-derive. The next slice is cut from what just became true, not from the original plan's step two.
The loop makes the roadmap a steering instrument rather than a promise. Plans made in advance answer "what did we think would happen?"; execution-time slices answer "what did happen, and what is the right next move?" — which is the only question execution can actually act on.
The honest costs
Execution-time slicing has real costs, and pretending otherwise is how teams slide back to big plans:
- The destination can drift. Slice-by-slice derivation optimises locally; without a stated direction, small correct steps can assemble into something nobody wanted. The direction text is the counterweight — it is what the slicing is for.
- The owner sees fewer grand plans. Some stakeholders read a detailed up-front decomposition as certainty. Execution-time slicing replaces that certainty with delivery evidence, which is a trade worth making and worth explaining.
- Each derivation is work. Cutting the next slice well requires reading the current state. This is real effort — and it is the effort that big-design-first defers and then pays with interest during execution.
Roadmap slicing in YATFA
Slicing in YATFA is execution-time by construction: a direction is stated as a roadmap, and the platform derives the next slice as a ticket only when the previous one has landed — against the current code, with the direction's reasoning carried into the brief. Directions that stop producing derivable slices surface honestly as paused rather than pretending to progress. See roadmaps in YATFA and the gate above them, proposals.
Frequently asked questions
Doesn't slicing as you go mean never finishing?
It means finishing the right thing incrementally. The completion risk comes from drift, and the counterweight is the direction statement: slices are derived toward it. A direction whose slices keep landing but never approach the goal has a direction problem — visible immediately in a slicing setup, and invisible for months inside a big plan.
How big should a slice be?
Small enough that one review can genuinely verify it, large enough to be a coherent outcome rather than a commit. The practical test: can its acceptance criteria be checked mechanically, and would a rejection cost hours or days? Hours is a slice; days is several slices.
Is this just agile again?
The ancestry is honest — iterative delivery, working software over documentation. What agent-driven work changes is the cost structure: deriving the next slice and writing its brief is cheap enough for a platform to do it every cycle, and the slices land verified without burning human review attention. The planning cadence that was a ceremony becomes a mechanism.