Value Stream Mapping

Visualize the entire flow from idea to value-delivered. Identify waste (handoffs, queues, rework). The First Way operationalized.

Overview

What value stream mapping is

Value Stream Mapping (VSM) is a Lean-manufacturing technique from the Toyota Production System, popularized in the late 1990s and now standard in software DevOps. The DevOps Handbook (Ch 4): "A value stream is the sequence of activities that an organization undertakes to deliver upon a customer request."

Three numbers per step

For each step, VSM measures three numbers.

Lead time (LT) — Wall-clock time from arriving at the step to leaving it
Process time (PT) — Actual hands-on work time
Wait time (WT) — Time spent waiting: in queues, for approvals, for environments

> [!IMPORTANT] The interesting ratio is PT / LT. In most software value streams it is shockingly low, 5-15%: 85-95% of lead time is WAITING, not doing.

Code review — 2-5 days — 30 min — 0.5-2%
Pre-prod test environment — 4 hours, waiting for environment — 15 min running tests — 6%
Deploy approval — 24-72 hours — 5 min — 0.1%

Worked example

A team had a 4-month lead time from commit to production. VSM revealed where it went.

Code — 2 weeks
Review — 3 weeks, waiting for senior engineer
QA queue — 4 weeks, waiting for QA team
Stage deploy — 1 week, waiting for env provisioning
UAT — 2 weeks, waiting for product owner
Prod approval — 3 weeks of committee meetings
Prod deploy — 1 week of deploy windows

The actual "work" in those 4 months was ~3 days. The fix: parallelize reviews, shift QA into the team, automate environment provisioning, reduce approval committees. Lead time dropped from 4 months to 3 days.

Practices to reduce lead time

Code review wait — Small PRs ( [!TIP] For interview prep: walk through LT / PT / WT, explain why PT/LT is so low, apply VSM to a hypothetical scenario, and connect VSM to the First Way and the DORA Lead Time metric.

Key concepts

Value stream: The full sequence of activities from idea to value delivered. For software: code → review → build → test → stage → deploy → run → learn. Every value stream has waste (waiting, handoffs, rework).
Lead Time (LT): Wall-clock time from arriving at a step to leaving it. Includes both process time and wait time. The DORA "Lead Time for Changes" metric measures total LT for the whole stream.
Process Time (PT): Actual hands-on work time. The "real" work being done. Usually a small fraction of Lead Time in software value streams.
Wait Time (WT): Time spent in queues, waiting for approvals, environments, reviews, etc. The biggest source of waste in most software value streams. The lever for improvement.
PT/LT ratio: Process time / Lead time. Most software value streams: 5-15%. This means 85-95% of lead time is WAITING. The improvement target is to raise this ratio by reducing wait time, not by working harder.
Current state vs future state: Map the current value stream first (with metrics). Then design the future state (target lead times). The gap between them is the improvement roadmap.

When to use it

When a team's Lead Time (DORA metric) is poor — VSM identifies WHERE the time is going
Before a DevOps transformation — map current state so you know what's changing
After a transformation — measure improvement and identify new bottlenecks
For continuous improvement — re-map every quarter, focus on the largest current bottleneck

Interview questions

How would you do a value stream mapping exercise?
Most teams' Lead Time is dominated by code review. Why?
How does VSM tie back to DORA metrics?