Value Stream Mapping

Value stream mapping (VSM) is an exercise that records how work actually moves from a request to something a customer can use, block by block, with measurements at each step. It is the standard way to find out where delivery time is going when the answer is not obvious — which is most of the time.

It belongs to a capability published guidance calls visibility of work: “the extent to which teams have a good understanding of the flow of work from the business all the way through to customers, and whether they have visibility into this flow, including the status of products and features.” Together with related lean practices, that capability is reported to “predict both software delivery performance and organizational performance (which is measured in terms of profitability, market share, and productivity).”

How it is done

The procedure is specific enough to follow without a consultant. Gather stakeholders from every part of the stream — “the business line, design, testing, QA, operations, and support” — and “break the value stream into 5 to 15 process blocks,” recording in each block the activity performed and the team that performs it.

Where to put the block boundaries is not specified, and the useful convention is to put them where work changes hands. Handoffs are where queues form, so a boundary drawn inside one team’s work hides nothing, while a boundary at a handoff exposes the wait.

Then measure three things per block.

Metric	Definition	What it tells you
Lead time	“The time from the point a process accepts a piece of work to the point it hands that work off to the next downstream process”	Elapsed time, everything included
Process time	“The time it would take to complete a single item of work if the person performing it had all the necessary information and resources to complete it and could work uninterrupted”	The work itself, with nothing in the way
%C/A	“The proportion of times that a process receives something from an upstream process that it can use without requiring rework”	Whether the block upstream is producing usable output

The first two are the point of the exercise: their difference is waiting. Whether waiting or working dominates is what the map tells you rather than something to assume — but it is the ratio, not either number alone, that says where to look, and measuring only how fast people work cannot produce it.

Reading the finished map

The published guidance gives two signals to look for, and they diagnose different problems: “look for process blocks that produce poor quality work, which then require a lot of downstream rework (reflected in a low %C/A in the downstream process block), and for processes that have long lead times relative to the process time.”

So a long lead time with a short process time is a queue — the work sat. A low %C/A in a block means the block before it is handing over something unusable, and the fix is upstream of where the pain is felt. Those call for different responses, and conflating them is how teams end up adding review steps to a problem that was actually waiting.

The reason a map can surprise people who have been measuring diligently for years is that queues are invisible in the systems most organizations already have. Those systems track whether people are occupied — and they are. Work waiting in a handoff does not appear as anyone’s idle time, so a long lead time with a short process time is a finding that existing dashboards structurally cannot show.

Two rules that decide whether it works

Record reality, not the documented process. The instruction is emphatic: “you always record the state of the processes as they really are on the day the exercise is performed. Make sure that you determine the actual metrics, not what people would like the metrics to be.” Code review takes four days on average, not the four hours it takes when someone senior is waiting. A map of the intended process will conclude that the process is fine.

Map the whole stream, with the whole room. Both published pitfalls point here. The first is “overestimating the state of organizational knowledge,” with a blunt justification — “in any organization, nobody has a good view into the whole value stream.” The second is “failing to map the entire value stream.” A map that begins at “developer picks up ticket” omits however long the request waited to become a ticket, which is frequently the largest single block.

Both rules are really the same rule: the exercise is worth doing because it produces knowledge no individual has, and each shortcut removes exactly the part nobody could have told you.

What it is not

A map is a snapshot, and the guidance is clear that ongoing visibility is a separate thing: VSM depicts how work moves, but “to get ongoing visibility into the flow of this work, you need a more dynamic view” — a card wall, a storyboard, or a kanban board, with work-in-progress limits to manage flow. Drawing a map and not changing how work is displayed day to day leaves you with a document.

It is also not a one-off. The recommendation is to build “a future-state value stream map that reflects the optimal state of the value stream at some future date (for example, in 6 months to 2 years)” and for stakeholders to agree to re-run the exercise on a schedule — “for example, every 6 months.” The cadence exists because the flow after a change is not the flow you mapped: the constraint may have moved somewhere else, or it may still be where it was, and the next map is how you find out which.

A practical note on scope: this is about the flow of work, not the flow of data. The two get confused because both are drawn as boxes and arrows, but a lineage diagram answers where a number came from, while this answers why a change took six weeks.

One closing caution on how to use the result. A map typically surfaces five or six things worth fixing, and the standard advice is to pick one — but be precise about why, because “anything else changes nothing” is too strong. Throughput is set by the narrowest point, so improving elsewhere does not raise it. The time a single change takes is a sum, so improving elsewhere shortens it a little: two hours of work plus forty of waiting becomes forty-one hours if you halve the work, which is a real if unimpressive gain. Decide which of the two you are trying to move, along with rework, before choosing where to spend the effort.

A second precision on the same point: the longest wait is the right first suspect and not automatically the capacity constraint. A queue can be long because something upstream batches, because a handoff runs weekly, or because of a scheduling rule, none of which is a shortage of capacity at that step. Distinguishing them is what keeps the next improvement from being aimed at the wrong thing.

The most common thing a first map recommends is reducing the size of the changes moving through it, covered under small batches; the outcome measures that should move afterwards are the DORA metrics. How the map, the batch size, and the metrics fit together is worked through in Six Weeks of Waiting, Two Days of Work.

Reference: DORA, Visibility of work in the value stream (checked September 2026), which credits its mapping technique and diagrams to Jez Humble, Joanne Molesky, and Barry O’Reilly, Lean Enterprise (O’Reilly, 2014).