Lesson 0042 · Initiative Lead · Module 1
Shape User Stories into Vertical Slices
A flat backlog hides the user journey and rewards component work. A story map lets the team cut the smallest end-to-end path that can teach something.
Mission tie-in: slicing is software design. It decides dependency order, integration timing, feedback speed, and whether the architecture grows around real behavior or imagined reuse.
Knowledge: the story is a conversation
A user story sentence is a placeholder, not a miniature contract. “As a customer, I want to create a return so that I can receive a refund” omits policy, failure, evidence, state, accessibility, and the outcome being tested. Its value is the conversation it starts.
Turn the workflow from lesson 0041 into a two-dimensional story map:
| Start request | Check eligibility | Choose resolution | Return parcel | Track outcome |
|---|---|---|---|---|
| signed-in order | domestic / unopened | refund to original | carrier label | status page |
| guest order | opened / damaged | exchange | QR drop-off | email and SMS |
| gift order | international | store credit | home collection | agent contact |
Pilot slice: the first row, with manual warehouse confirmation behind the scenes. It is narrow in variation and complete across the journey.
A vertical slice crosses the system and produces observable behavior. “Create return table,” “build rules API,” and “design status component” are horizontal layers; none helps a user or tests the integration alone. “Eligible signed-in customer receives a label and can see status” crosses UI, policy, persistence, carrier, and telemetry—but only for one controlled case.
Thin vertical slices reduce risk by converting integration risk into early evidence. Almost all schedule risk in software is unknown interaction—the mismatch between what one part assumes and what another provides—and an unknown interaction can only be observed by running the whole path. A horizontal layer defers every one of those observations to a single late integration moment, and by then the cost of each discovered mismatch is multiplied by all the work already built on the wrong assumption. A vertical slice pays a small fixed cost—touching every layer for one narrow case—to buy a cheap early failure. You are not buying progress; you are buying the right to be wrong while being wrong is still affordable.
The second mechanism: a layer cannot be judged, but a demonstrable behavior can be measured, shown to a user, and used to choose what to build next. It stops paying where there is no interaction to discover—a pure algorithm change inside one module—or where the path cannot yet be exercised at all, in which case slice against a contract-level fake and say plainly that the integration risk is still open.
Attach examples before implementation. Use Given/When/Then when it clarifies, but the syntax is less important than the specificity:
Happy: Given an unopened domestic item delivered 12 days ago, when its purchaser requests a return, then approve it and create one label.
Boundary: Given the same item delivered 31 days ago, then refuse it with reason outside return window and offer agent contact.
Retry: Given an approved request whose label call timed out, when the call is retried with the same intent, then show the original label rather than buy another.
Guardrail: A keyboard-only customer can complete the happy path and understand any refusal.
Good acceptance examples cover the rule, its boundary, a meaningful failure, and a guardrail—not every implementation detail. Refine them with product, design, engineering, and whoever tests or operates the flow. This “three amigos” conversation catches ambiguity when it is still cheap.
Do not create a bureaucratic “Definition of Ready” gate. Use a readiness question: does the team understand the user and outcome, examples, dependencies, design state, telemetry, and unresolved risk well enough to start while preserving room to learn?
How the lead actually cut it
Week 3, seven people, ten weeks to the 30 September pilot. Product wants rows one and two, because guest orders are 29% of demand and the sponsor keeps asking about them.
The lead's first question is not “what can we build?” but “if this slice ships and the median does not move, what will we have learned?” Row one answers it: automatic eligibility plus visible status is either the cause of faster resolution or it is not. Guest orders would double the identity and fraud surface without changing what the slice can teach, so guest becomes an explicit non-goal with a revisit trigger rather than a silent omission.
Karl argues the opposite order: eligibility engine first, because policy is the hard part. The lead rejects it for a specific reason rather than a preference—policy correctness can be proven cheaply with executable examples, while nothing but a live path can prove the carrier call, the retry, and the status loop. Sequence what only production-shaped evidence can settle. Bea, the support lead, dissents on the cohort; her belief that guests will dominate the queue is written down with the test that would settle it, and it resurfaces in lesson 0050's week-four review.
The manual seam is chosen by arithmetic. With 71% of sampled cases matching written policy, roughly 46 of the pilot's 160 daily requests need a human against a guardrail of 50 per day—so the slice automates the clean 71%, routes the rest to an agent queue, and instruments queue depth from day one. Slice one shipped in nine working days, and on day four it surfaced the carrier's duplicate-label behavior on retry: a defect that, under a layered plan, would have arrived in week seven with a policy engine, a UI, and a notification service already built on top of it.
| Slice by | Keep | Defer |
|---|---|---|
| persona or cohort | one user's whole path | guest, admin, international |
| business-rule variation | one complete policy case | exceptions and alternate resolutions |
| operational mode | manual step behind a seam | automation after evidence |
| quality threshold | safe pilot volume | global scale after measurement |
- A vertical slice has to be small in value.
- It has to be small in variation and complete in path. One cohort, one rule, one resolution—but all the way through. Teams that shrink value instead of variation end up shipping a whole journey badly rather than one journey properly.
- Layers are fine as long as we integrate weekly.
- Weekly integration of layers still defers the interaction discovery; it just batches it into smaller surprises that arrive after the assumptions have already spread. The unit that retires risk is a demonstrable behavior, not a merge.
- Given/When/Then is what makes an example good.
- Specificity is what makes it good; the syntax is packaging. A team that adopts the keywords and keeps vague examples now has ambiguity and a test framework to maintain.
- Manual seams are technical debt.
- A manual seam with an owner, a volume limit, and a removal trigger is a deliberate deferral. The version without those three is the debt—and it is how a pilot workaround becomes someone's permanent job.
When this is the wrong move
Do not force a vertical slice when there is no integration to discover: a batch recalculation inside one service, a change with no user-visible surface. Do not force one when the scaffolding costs more than the risk—if a slice needs a fake adapter, a flag, a seeded cohort, and a data migration to demonstrate anything, the honest move may be a spike instead. And in a release that legally cannot expose partial behavior to anyone, slice for internal evidence and accept that the external release is a single event with a rehearsed reversal.
Skill: find the learning slice
Which item is a vertical slice?
Acceptance examples should primarily specify:
Why keep manual work in an early slice?
Practice: cut a journey, not a layer
Build a story map for one initiative: backbone activities left to right, variations beneath. Draw a line across the smallest slice that reaches an outcome or answers a risky assumption. Write four examples: happy path, rule boundary, meaningful failure, and guardrail. Then identify the manual seam that could remove the largest unproven automation.
In the lab and the capstone. The lab's phase-4 checkpoint makes you cut one slice through the existing returns code and prove it end to end—the rollout gate for that slice is written as a test rather than a paragraph. The worked artifacts are the story map and its executable examples in the strong capstone packet; trace how the boundary example there becomes a refusal reason in the contract and a segment in the rollout telemetry. Compare with the weak version's story map and examples, where the backbone is a component list and every example describes a happy path.
Reveal: the slice quality test
A slice is useful when it can be deployed independently, demonstrated in user language, observed with a named measure, and used to decide what to do next. If its demo is “the endpoint returns 200” or “the schema migrated,” it is a task bundle, not yet a product slice.
- In two sentences, explain to a new lead why a narrow end-to-end slice is safer than a finished layer, without using the word “agile”.
- Take the next item on your own backlog. Rewrite it as a slice: name the cohort, the one rule, the manual seam, and the measure that would move.
- Predict the failure: if a team plans by layers for a quarter, what does the first integration week look like, and which assumption will turn out to have been copied into four places?
Your win
You can turn a workflow into a story map, capture behavior with concrete examples, and cut a narrow end-to-end slice that earns evidence before infrastructure.
Read and watch deeper
- User Story Mapping, Jeff Patton — ch. 4–8: the backbone, release slices, and using maps for discovery and delivery.
- Specification by Example, Gojko Adzic — ch. 2–4: deriving scope and tests from concrete examples collaboratively.
- Essential XP: Card, Conversation, Confirmation, Ron Jeffries (2001) — the origin of the three Cs, and why the sentence on the card is the least important part.
- Reference: Initiative Playbook · story-map and example templates.
Ask your agent-teacher for five smaller slices, then reject every proposal that does not reach observable behavior end to end.