Value Stream Mapping
Who desires what changed reality — and where does their value stop flowing?
Value stream mapping is the practiced skill of seeing how a desire becomes a proven outcome. It follows one real unit of value across work, decisions, waits, handoffs, rework, and feedback. The map is not the skill. Learning to observe the real flow, improve its constraint, and help another player see it is the skill.
The Skill
- See value — name the player, their desire, and the changed reality they recognise as valuable.
- See flow — follow one real instance from trigger to proof, including what the official process hides.
- Improve flow — question requirements, delete waste, simplify what survives, shorten feedback, and automate only stable work.
- Coach flow — ask questions that let another player build and improve the map themselves.
This is how the Playbook's Flow of Value becomes practiced execution:
Desire → Quest → Game → Plan → Performance → better-informed Desire
Inside-Out Storyselling uses this observed flow as the route from an inside-out value setpoint to an outcome the receiving player appreciates.
Before You Map
Choose a stream narrow enough to observe end to end. Do not map “sales”, “product development”, or “customer service”. Map one unit such as “a qualified customer request becomes a delivered quote” or “a reported defect becomes a verified fix”.
Begin inside-out. Reaffirm the value-system setpoint before mapping the activity around it. Write these five statements first:
| Prompt | Test |
|---|---|
| Value setpoint — What is worth serving? | Name what matters and what must not be traded away. |
| Player — Who receives the value? | Name a person or specific role, not “the business”. |
| Desire — What progress do they want? | Describe changed reality, not a feature or activity. |
| Appreciation — Why would they value it? | Use the receiving player's language, not an internal KPI. |
| Proof — How will they know it arrived? | Name observable evidence at the receiving end. |
If those answers are unclear, return to the Outcome Map. Do not optimise a stream whose value has not been defined.
Map One Real Round
Use evidence from a recent instance: timestamps, messages, tickets, documents, commits, decisions, receipts, and the people who performed the work. Map what happened, not what the procedure says should happen.
- Start at proof and walk backwards — find the output the player actually received, then trace it to the trigger.
- Record every step — name the action, owner, input, output, and evidence.
- Separate work from waiting — measure touch time and elapsed time; do not hide queues inside a step.
- Mark every handoff and return — record incomplete or inaccurate work that travelled backwards.
- Ask whether each step changes the outcome — distinguish value, necessary support, and waste.
- Find the constraint — identify the point limiting the flow of the whole stream, not merely the most annoying step.
VALUE STREAM MAP
════════════════════════════════════════════════════════════
[TRIGGER]
│
▼
┌─────────┐
│ STEP 1 │ C/T: ___ Wait: ___ %C&A: ___%
└────┬─────┘
│ ░░░░░░░░░ (wait time)
▼
┌─────────┐
│ STEP 2 │ C/T: ___ Wait: ___ %C&A: ___%
└────┬─────┘
│ ░░░░░░░░░░░░░░░░░░░░░ (bottleneck!)
▼
┌─────────┐
│ STEP 3 │ C/T: ___ Wait: ___ %C&A: ___%
└────┬─────┘
│
▼
[OUTPUT]
Flow Efficiency = Total Touch Time / Lead Time × 100
════════════════════════════════════════════════════════════
The Value Stream Map is the second flow engineering map. It makes delay and rework visible so the player can improve the constraint instead of making every step busier.
Metrics
| Metric | Measures | Why It Matters |
|---|---|---|
| Cycle Time (C/T) | Touch time required at one step | The work itself |
| Wait Time | Time between steps | Where flow breaks |
| %C&A | % Complete & Accurate at handoff | Quality of flow |
| Lead Time | C/T + Wait | Total time from trigger to output |
| Flow Efficiency | Total touch time / lead time | How much elapsed time contains work |
Use the first observed round as the baseline. A universal percentage is not the goal; improved flow to the player's desired outcome is. Never reduce lead time by hiding rework, lowering quality, or moving delay outside the measured boundary.
Seven Wastes
Toyota's waste categories adapted for knowledge work:
| Waste | Manufacturing | Knowledge Work |
|---|---|---|
| Waiting | Parts not arrived | Waiting for approval |
| Overproduction | Making too much | Building unused features |
| Rework | Defects | Bug fixes, revisions |
| Motion | Walking to tools | Context switching |
| Transport | Moving materials | Handoffs between teams |
| Inventory | Excess stock | Work in progress |
| Over-processing | Unnecessary polish | Gold-plating features |
Improve One Constraint
Improve in this order. Do not automate waste.
- Question requirements — who owns this requirement, and what evidence proves it is needed?
- Delete — remove a step, approval, handoff, queue, report, or batch. Define the evidence that would require adding it back.
- Simplify — combine surviving steps, clarify ownership, shrink batches, and make inputs complete at the source.
- Accelerate feedback — shorten the distance between action and proof; run a smaller round sooner.
- Automate last — automate only a necessary, stable, understood step with a measurable failure signal.
Change one constraint, run the stream again, and compare:
| Evidence | Before | After |
|---|---|---|
| Player outcome delivered | ||
| Receiver appreciation | ||
| Lead time | ||
| Total touch time | ||
| First-pass complete and accurate | ||
| Handoffs and returns | ||
| Work in progress |
Keep the change only when the receiving player gets equal or greater value with better flow. Record what was deleted, what happened, and the condition that would justify adding it back.
Coaching Guide
The coach does not draw the learner's map. The coach keeps attention on reality and asks:
- Who is the player, and what do they desire?
- Which value-system setpoint does this stream serve?
- What is one unit of value in the receiving player's language?
- How would that player express genuine appreciation for the change?
- Show me the most recent unit that completed the journey. Where is its proof?
- What happened immediately before that? How do we know?
- Where was nobody changing the outcome?
- Where did incomplete work move forward or come back?
- Which point governs the pace of the whole stream?
- What feels dangerous to delete? What evidence would make deletion safe to try?
- What is the smallest next round that can test the change?
- What did the result teach us about the player's values and desire?
Pain focuses attention. Desire gives direction. Practice builds confidence. Flow is both the goal and the reward: capability meets a worthy challenge, evidence arrives quickly, and the next move becomes clear.
Worked Example
Stream: A qualified customer request becomes a delivered quote.
| Step | Touch | Wait | %C&A | Observation |
|---|---|---|---|---|
| Capture request | 10 min | 0 | 60% | Required site details often missing |
| Clarify requirements | 20 min | 2 days | 90% | Email handoff and customer wait |
| Price solution | 45 min | 1 day | 80% | Approval required above an inherited threshold |
| Approve quote | 10 min | 3 days | 100% | Largest queue; few quotes are changed |
| Send quote | 5 min | 2 hours | 100% | Batched at the end of the day |
The visible pain is slow quoting. The constraint is the approval queue, but the first experiment is not “automate approvals”. First question the threshold and its owner. Delete approval for a bounded, low-risk quote class with an add-back trigger for pricing errors or margin breach. Then run another round and compare delivery, lead time, and first-pass accuracy.
Common Failure Modes
- Mapping the official process instead of following one real instance.
- Starting with departments rather than a player, desire, and unit of value.
- Treating every activity as value because someone is busy doing it.
- Optimising one step while increasing inventory or delay elsewhere.
- Blaming people for queues created by system design.
- Automating an approval, report, or handoff before testing whether it can be deleted.
- Declaring success from speed alone when the player receives less value or more defects.
Competency
| Level | Observable capability |
|---|---|
| See | Follows one real unit from desire to proof and separates touch time from waiting. |
| Map | Makes steps, ownership, evidence, handoffs, rework, and the constraint visible. |
| Improve | Tests deletion before optimisation and proves the result with a second round. |
| Coach | Helps another player produce and improve their own evidence-backed map without taking over. |
Gate
Before moving to Dependency Map:
- Value setpoint, player, desire, appreciation, unit of value, and proof named
- One completed instance traced from proof back to trigger
- All steps documented with owner, evidence, and cycle time
- Wait time measured between steps
- Flow efficiency calculated
- Constraint identified for the whole stream
- Waste types categorized
- One deletion-first intervention tested with an add-back condition
- Before-and-after outcome, lead time, and quality recorded
- Learner can teach the map back or coach the next player through one round
Context
- Outcome Map — Previous: define what success looks like
- Dependency Map — Next: understand blockers
- Flow Engineering — The methodology these maps serve
- Process Optimisation — Improve the flow
Questions
Where does nobody touch the work, yet the player continues to wait?
- Which of Toyota's seven wastes is hardest to see in knowledge work, and why?
- Which requirement or approval feels most dangerous to delete, and what bounded experiment could test it?
- How do you map a value stream when the trigger is a customer intention rather than a physical event?
- Can the learner coach the next player without drawing the map for them?