Break down the work and build a vertical slice

Break the work so each unit closes something real

Assume you already have an implementation-ready specification for filtering unfinished tasks. If you split it into “one backend task,” “one frontend task,” and “one testing task,” all three can move while none independently completes a usable, judgeable behavior. You end up with partial outputs and hidden dependencies.

In this lesson you build Vertical Slice Plan v1: a plan that decomposes one complete specification into smaller work units while defining at least one end-to-end vertical slice that crosses only the layers required to close an observable criterion. Every unit records its outcome, evidence role, dependency order, and merge/rollback boundary.

This lesson does not execute code and does not start an AI run. It designs the work units and their controlled order. FND-003 executes one unit through the next workflow.

Estimated active time: 50 minutes.

This lesson is for you if: you have an implementation-ready specification but your backlog is still split into large, layered, or ambiguous tasks and you cannot show which unit independently produces useful or judgeable evidence.

This lesson is not for: redefining the specification, splitting only by file or specialty, choosing the smallest diff without an outcome, or executing code/an AI run.

Hard prerequisite — FND-001-P05: you can reconstruct and review an implementation-ready specification without hidden decisions.

Short prerequisite probe

Use this packet:

• Spec ID: TASK-FILTER-SPEC-v1
• Problem: the user needs to view unfinished tasks only.
• IN: choose All or Unfinished and return to All.
• OUT: persistence of the selection, schema change, redesign.
• Constraint: completed/unfinished meaning and the data contract do not change.
• AC-01: Unfinished shows unfinished tasks only.
• AC-02: returning to All restores the normal view.
• Readiness: unresolved contradictions = 0; blocking unknowns = 0; human review is complete.

In a few lines, reconstruct the outcome, scope boundary, two criteria, and the main constraint, and explain why this packet is sufficient to begin decomposition.

PASS: reconstruct the packet without adding a new requirement and distinguish goal, boundary, criterion, and constraint.

If this packet is not independently clear to you, repair only the fragile FND-001-P05 skill. Decomposition must not hide ambiguity in the specification.

Choose the amount of support you need

Every route produces the same Vertical Slice Plan v1 and meets the same evidence bar.

Four-concept route probe

1. What does a good work unit contain beyond a file name or specialty label?
2. Why is a frontend-only or backend-only task not necessarily a vertical slice?
3. Why can the smallest code diff be smaller than the smallest useful slice?
4. What decisions do dependency order and rollback boundary make explicit?

4/4 → Fast Path; 2–3/4 → repair only the fragile concepts; 0–1/4 → foundation route.

• Foundation: follow the complete task-filter example and template.
• Repair: rebuild only the relevant misconception.
• Experienced/Fast Path: go directly to the independent case; ambiguity and dependency pressure are higher, but the evidence bar is unchanged.

Mental model: a vertical slice crosses value, not just a layer

The sequence at this point is:

Implementation-Ready Spec → decomposition → useful vertical slice(s) → dependency/rollback plan → FND-003 execution

The four concepts answer different questions:

A horizontal split may be convenient for specialist ownership, but if no unit independently delivers an outcome, it is not yet a strong delivery decomposition.

The four foundation concepts

1. Task decomposition

Break the specification into units with a goal, boundary, and evidence role. A strong unit is not merely “change file X”; you can state what becomes correct, observable, or reviewable when the unit is complete.

2. Vertical slice

A small end-to-end slice that crosses the layers needed to complete one observable or valuable behavior. It does not need to touch every system layer—only the ones required for that behavior.

3. Smallest useful slice

The smallest slice that still produces a real outcome. An empty component, unused schema, or wiring with no behavior may be small, but it is not yet useful.

4. Dependency order and rollback boundary

Order should be justified by dependency or risk. Each unit should have a comprehensible merge and rollback boundary where possible, so failure in one unit does not make the whole plan ambiguous.

Build Vertical Slice Plan v1

Record these fields for every candidate work unit:

1. Unit ID and type: Vertical Slice, supporting dependency, or verification support.
2. Bounded outcome: what is true when this unit is done?
3. Criterion(s) closed: which acceptance criteria are actually closed here?
4. Layers touched: only the layers required for the outcome.
5. Prerequisites: what known dependency must already hold?
6. Evidence: what proves the outcome is closed?
7. Order reason: why does this unit come before or after another?
8. Merge boundary: what can be independently reviewed or integrated?
9. Rollback boundary: if evidence fails, exactly what is reversed?
10. Next unit: what follows and why?

Reusable blank scaffold

Fill this template for every work unit. Next unit must include both the next-unit identity and the handoff reason.

Unit ID / type:
Bounded outcome:
Criterion(s) closed:
Layers touched:
Prerequisites:
Evidence:
Order reason:
Merge boundary:
Rollback boundary:
Next unit ID:
Next-unit handoff reason:

The machine-readable version is artifacts/vertical_slice_plan_v1_template.json. This scaffold records the work plan only; it contains no code-execution or AI-run instructions.

Start decomposition from criteria and outcomes, not from team structure or folders. Then identify the layers required to close the outcome.

AI may suggest candidate slices, critique possible dependencies, or identify missing evidence. In this lesson it must not propose or execute code/test changes or execution steps. It may not invent new requirements, redefine acceptance, or own the final sequencing/boundary judgment; change execution remains in FND-003.

Worked case: unfinished-task filtering

Input is the same TASK-FILTER-SPEC-v1:

• AC-01: Unfinished shows unfinished tasks only.
• AC-02: All restores the normal view.
• Constraint: the data contract and status semantics do not change.
• OUT: persistence and redesign.

A reasonable decomposition is:

WU-01 — Vertical Slice

Outcome: the user can switch between All and Unfinished and observe correct behavior in both states. Criteria closed: AC-01, AC-02 Layers touched: view-selection control + existing list state + existing render path Evidence: mixed-status list, return-to-All check, all-completed case Order reason: produces the earliest real feedback without adding persistence or schema changes. Merge boundary: bounded to the view-filter behavior. Rollback boundary: removing this filter-selection path restores the previous All-only behavior.

WU-02 — Verification support

Outcome: prove the data-contract constraint and existing-list regression remain intact. Criterion/role: supports acceptance of WU-01; it does not pretend to be a separate value slice. Evidence: contract/schema inspection + existing-list regression check Order reason: this evidence must close before final acceptance of WU-01. Rollback boundary: if the contract changed, WU-01 is not accepted and the related change is rolled back or replanned.

The plan deliberately avoids “all frontend first, all backend second.” It starts with observable behavior and attaches only the dependencies needed to close it.

Four common failure modes

Failure 1: split by specialty

You create a frontend task and a backend task, but neither closes a user criterion. Repair: start from an observable criterion and collect the required layers inside one vertical slice.

Failure 2: build all infrastructure before behavior

Substantial work accumulates with no real feedback. Repair: find the smallest judgeable flow; introduce infrastructure only to the degree required by that slice.

Failure 3: confuse smallest diff with smallest useful slice

An empty component or interface is called a “slice.” Repair: ask which user-visible criterion the unit closes. If none, either state its supporting role or re-slice it.

Failure 4: parallelize across an unresolved dependency

Two units begin with incompatible assumptions about a shared state or contract. Repair: expose the shared dependency, record the order reason, and define rollback boundaries before parallel work.

Experienced bridge: hidden dependencies and parallel work

In real systems, perfect independence is not always possible. Two small slices may depend on one shared capability. The goal is not zero dependency; it is known, bounded dependency with an explicit sequencing reason.

Suppose Slice A displays a new state and Slice B edits the same state, while the shared state contract is not yet settled. Starting both in parallel creates apparent speed but increases rework risk. A stronger plan records the shared capability as a prerequisite, names the evidence required to stabilize it, and separates the parts that can genuinely proceed independently.

Stress the plan with:

• one bounded shared dependency;
• incomplete evidence for one sequencing choice;
• a cheap rollback for one slice and an expensive rollback for another;
• pressure to parallelize before the contract is clear.

Sometimes the right result is “replan before start,” not “run everything in parallel.”

Decomposition options and trade-offs

• Horizontal/layer split: easy for specialist ownership, but may delay user feedback.
• Vertical slice: closes observable outcomes earlier, but may require cross-layer coordination.
• Dependency-first split: useful for a genuinely shared capability or migration, but supporting work must stay linked to a specific value slice.
• Risk-first slice: explores expensive uncertainty early, if the outcome and evidence are explicit.
• Smallest-diff split: reduces code-review size, but does not guarantee a useful or acceptable unit.

No template replaces judgment. The invariants are bounded outcome, at least one vertical value slice, explicit evidence, a reasoned order, and a rollback boundary.

Guided and independent practice

Guided case — Order search

Specification packet:

• Problem: the user must find an order by full order number.
• IN: exact order-number search on the orders page.
• OUT: fuzzy search, customer-name search, redesign.
• Constraint: order schema and the existing list path do not change.
• AC-01: exact match shows the correct order.
• AC-02: no-match produces a clear message.
• AC-03: the existing list still works without search.
• Readiness: no requirement conflict is reported and the existing lookup capability has been verified.

Build a Vertical Slice Plan v1 with 2–4 work units. At least one unit must close AC-01 or AC-02 end-to-end. For every unit record outcome, evidence, prerequisites, order reason, merge/rollback boundary, and the next-unit identity plus handoff reason. Do not produce code or an AI run.

Independent case — Fast Path destination: Avatar refresh

Specification packet:

• after a successful replacement, the new avatar is visible on the next profile visit;
• failure preserves the current image and shows a clear error;
• upload API and storage provider remain unchanged;
• crop editor, history, and profile redesign are out of scope;
• cache ownership for the current path is known;
• AC-A: success shows the new image on the next visit;
• AC-B: failure preserves the previous image and shows a clear error;
• AC-C: upload/storage contracts remain unchanged.

Decompose this specification into 2–4 work units. Include at least one smallest useful vertical slice, a dependency order, rollback boundaries, and a next-unit handoff with identity and reason. Do not copy the task-list wording or add execution steps that belong in FND-003.

When is the slice plan actually acceptable?

Before accepting Vertical Slice Plan v1, check:

1. Does every work unit have a clear outcome and evidence role?
2. Does at least one smallest useful slice close an observable criterion end-to-end?
3. Are supporting dependencies attached to a named slice rather than pretending to be independent value?
4. Is sequencing justified by dependency or risk?
5. Is each unit's merge/rollback boundary explicit or explicitly shared with a reason?
6. Does the plan preserve the specification rather than redefining it?
7. Does execution remain for FND-003?
8. Is plan acceptance based on human review and evidence rather than self-report?

Machine checks can validate completeness and links; judging slice sufficiency and acceptance still requires human review.

Assessment and transfer

Assessment covers five layers: bounded definition, application to a fresh specification, diagnosis of a flawed decomposition, a human sequencing/parallelization decision, and transfer to another domain.

To pass blocking items:

• all four concepts must be visible in the artifact;
• at least one true vertical slice must close a criterion;
• smallest diff must not be confused with smallest useful slice;
• dependency order and rollback boundaries must be justified;
• the plan must be independently reviewable without oral context;
• the human Q4 decision must record the verdict, rationale, and residual uncertainty; if none remains, explicitly record NONE / closed;
• AI execution must remain outside this lesson.

The final evidence is Vertical Slice Plan v1 plus its rationale and human decision record.

Technical references and standard status

For requirements-engineering context, ISO/IEC/IEEE 29148:2018 remains the published Edition 2. ISO currently marks it “to be revised.” Edition 3 is still a Draft International Standard under development and has not replaced the 2018 publication.

For slicing, the Agile Alliance experience report provides a practical example of the distinction between vertical and horizontal slicing and of delivering small valuable increments. It supports the conceptual distinction; Vertical Slice Plan v1 is this lesson's teaching artifact and is not copied as a mandatory external template.