Value Stream Mapping

Value stream mapping (VSM) records how work moves from a request to something a customer can use, with activities, responsibilities, and measurements at each step. It helps a group investigate where delivery time goes and choose an improvement.

DORA describes visibility of work as understanding the flow from business to customer, including the status of products and features. Its research associates this capability and related lean practices with delivery and organizational performance. A map makes that flow available for joint examination.

How it is done

DORA recommends gathering stakeholders across business, design, testing, operations, and support, then starting with 5 to 15 process blocks. Record the activity and responsible team in each block. The suggested scale makes the path readable; it need not hide detail that matters to the investigation.

Handoffs are useful candidate boundaries because work often waits there. Queues also form inside a team, for example before a shared test environment or review. Subdivide a block when needed to expose those waits, while retaining the connection to the full stream.

Then measure three things per block.

Metric	Definition	What it tells you
Lead time	Elapsed time from accepting an item to handing it to the next process	Elapsed time, everything included
Process time	Estimated uninterrupted time to complete an item with necessary information and resources	The work itself, with nothing in the way
%C/A	Share of incoming items usable without rework	Whether the block upstream is producing usable output

Compare lead and process time for the same work and boundary, with a stated clock and treatment of rework. Their gap identifies time to investigate. It is not enough to distinguish active rework, unavailable information, interruptions, and queueing without looking at the item’s path.

Reading the finished map

DORA recommends investigating both low %C/A and long lead time relative to process time. They highlight different questions: whether the input met the receiving process’s needs, and why the item remained in the process so long.

Inspect the events behind those signals. Low %C/A can lead to upstream defect prevention, clearer acceptance criteria, or a better handoff. Long elapsed time can lead to an investigation of active work, rework, scheduling, and waiting. Agree on the cause before adding a control or changing capacity.

A dashboard of staff utilization does not measure item waiting time. Flow dashboards can expose it through timestamps, work in progress, and age. The map complements those measurements by connecting the stages and helping the people involved interpret what happened.

Two rules that decide whether it works

Record the current process. DORA asks teams to use actual rather than desired metrics. Distinguish observed timings from estimates and stated targets, and use later items to check uncertain estimates. A fast urgent review is not a substitute for measuring ordinary review turnaround.

Map the relevant end-to-end stream. Bring together the people who perform and receive its work; no individual should be assumed to know every step. For request-to-customer delivery, include time before development starts. A narrower investigation can be useful, but its boundary must not be presented as the whole delivery time.

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 records a process at a point in time. DORA recommends a dynamic display, such as a card wall or Kanban board, for ongoing visibility, with work-in-progress limits to manage flow. Keep the map and the daily view connected as work changes.

DORA also recommends a future-state map and a schedule for revisiting the current state. Its examples use a six-month to two-year horizon and a six-month review cadence; choose intervals that fit the change being tested. Re-measure rather than assuming that a completed intervention moved the constraint.

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.

Choose the outcome before choosing the intervention: useful throughput, lead time, or rework. In a serial model with fixed work mix and quality and a continuously supplied, unblocked bottleneck, speeding another step does not raise the capacity ceiling. Improving upstream quality or reducing starvation can still raise useful output at the same bottleneck capacity. Lead time can also fall independently: if forty hours of waiting remain fixed, halving two hours of active work reduces forty-two hours to forty-one. State the model’s assumptions and verify the actual effect.

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.

One candidate improvement is small batches; DORA metrics can help assess delivery outcomes alongside the chosen local measures. How the map, batch size, and metrics fit together is worked through in Six Weeks of Waiting, Two Days of Work.

References

• DORA — Visibility of work in the value stream
• DORA — Value stream mapping for software delivery
• Jez Humble, Joanne Molesky, and Barry O’Reilly — Lean Enterprise (2014; mapping diagrams credited by DORA)