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.
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?
| 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 |
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.
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.
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.
- Agile Software Development, Alistair Cockburn — the “card, conversation, confirmation” model behind user stories.
- 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.