A2.06 · Decomposition
The value ladder
A ladder is a pile of stories put in order: each rung adds one usable capability, depends only on the rungs below it, and leaves the system runnable.
The earlier modules made good stories one at a time — value not tasks, the Connextra form, the INVEST tests. A value ladder is what those stories become when they are ordered: a dependency-ordered stack where value accrues from the bottom up and every prefix can be demonstrated. It is the structure the rest of the course plans, specifies, and builds over. Three dives: compose the rungs, order them by dependency, and keep the system runnable at every one.
A pile becomes a ladder
A pile is a set of stories with no order; a ladder is the same stories arranged so they stack. Three properties make a stack a ladder, and each is one dive below. Every rung is a capability — a vertical slice a role can exercise, not a technical task. Every rung depends only on rungs below it — the stack is a topological order of the dependency graph. Every prefix runs — building the bottom rungs leaves a system that can be demonstrated. Lose any one and the stack stops being a ladder.
The figure below composes a Portal ladder one candidate at a time. Pick a candidate to read whether it is a rung — a usable capability that fits the ladder — or is rejected as a task or an outsize wish that is not one rung of value. The four capabilities stack; the two non-stories do not.
Compose a Portal ladder · pick a candidate
A ladder is not a pile: every rung is a capability, ordered so value accrues from the bottom up — and the candidates that are not capabilities never become rungs.
Compose stories into a dependency-ordered ladder where each rung adds usable value and the whole remains runnable — the structure delivery is later planned over.
browse → enrol → open a lesson → track progress: four rungs, each a capability, each resting only on the ones below, the system demoable after every one.
The three dives
Each dive isolates one property of a ladder, in the arc compose → order → keep runnable: assemble the rungs as capabilities, order them so each depends only on rungs below it, and confirm every prefix still runs. Read them in order — A2.06.1 starts.
Compose the ladder
Assembling individual stories into one ordered ladder: each rung a usable capability, not a task. The move from a pile of stories to a stacked ladder.
Dependency order
Each rung depends only on the rungs below it: a topological order. Value accrues bottom-up, and ordering by value reconciles with ordering by dependency.
Always runnable
Every rung leaves the system runnable and demoable. This is the structure the roadmap layer later plans delivery over — one prefix at a time.
A2.06 composes the ladder; the chapter's remaining modules write its acceptance criteria, split a rung that is too big, and run the closing workshop that composes the whole Portal ladder. Return to the A2 module navigation to continue.
References
The story-and-release tradition the value ladder draws on, and where it connects in the course.
Sources
- Cohn, M. — User Stories Applied — stories as small units of value, ordered into a release plan.
- Humble & Farley — Continuous Delivery — keeping the system releasable after every increment.
- Hunt & Thomas — The Pragmatic Programmer — building in small, deliberate, provable steps.
Related in this course
- A2.06.1 · Compose the ladder
- A2.06.2 · Dependency order
- A2.06.3 · Always runnable
- A2.01 · Value, not tasks — why a rung is a capability.
- A2.03 · INVEST — Independent and Small, the per-rung tests.
- A1.04 · Two layers — the roadmap that plans over the ladder.
- A2 · Decomposition — the chapter.