Improve the journey a change takes to reach users. A value stream map shows processing, waiting, handoffs, and rework across the path to production.
Map the current path
Pick one service and a recent, representative change. Bring together the people who move it through development, review, validation, and operations.
- Set boundaries: commit to verified production here. Idea-to-user value is a broader map.
- Record each step: owner, processing time, queue before it, and evidence that permits the next handoff.
- Include reality: failed checks, rework loops, environment waits, and release windows. Label estimates.
Use one clock throughout. Processing includes automated work, not just human effort. Show parallel activity explicitly; do not add overlapping durations.
Change one constraint
Example: This sequential path takes 24 hours: 3 processing and 21 waiting. The 12-hour deployment queue is a candidate to investigate. Establish its cause before choosing a fix.
If a scheduled release window causes that queue, trial smaller, more frequent releases with the required checks intact. Compare elapsed time and failed changes over similar work. Keep the improvement only if the evidence supports it.
This map ends after production verification. DORA change lead time ends at deployment; label that boundary separately. Deployment also does not prove customer value, especially when a feature remains disabled.
Development waste
Faster coding has limited impact when a change spends most of its journey waiting. Waiting is only one kind of waste: unused features, repeated clarification, defects, and task switching also consume effort without improving the outcome. Keep review and validation for what they protect, and look at the friction around them: the queue before review, oversized changes, or unclear ownership.
Related: Little’s Law · APEL: from Sprints to flow · Observability.