Value Stream Mapping

The problem

Acme Shop's delivery team wants customers to be able to send returns with a second courier. The change is small, about a day of development, yet change DLV-214 reaches customers 22.5 working days after the request. Every team on the way is busy and reports its own step as fast: the product manager triages the request in an hour, code review takes 2 hours, the security team's review 2 hours, the platform team sets up a test environment in an hour, QA tests in 4 hours and the weekly change board spends an hour on it. Those numbers add up to 20 hours, 2.5 working days. The other 20 days pass in queues between the teams: the backlog, the wait for a reviewer, the security team's ticket queue, the platform team's environment queue and the wait for the next board meeting. (Acme's numbers are the example's own, not research findings; a day on this page is a working day of 8 hours.)

Nobody measures those waits, because nobody owns them. Each team improves the part it can see, so the security team is proud of a 2-hour review while the ticket waits 5 days in front of it, and when support asks when the feature will ship, every team answers for its own step and no one can give a date. Without a picture of the whole flow, a discussion about where to improve runs on opinions, and effort tends to go to the step whose owner complains loudest, or to a new tool for one team, while the queues stay where they are.

How it works

A value stream is every step, adding value or not, that a request passes through on its way to the customer. Value stream mapping draws that stream on one page, with a few measurements for each step, so that the people who own the steps see the same picture: where the work is done, where it waits and where it comes back for rework.

Where it comes from

Toyota drew material and information flow diagrams as part of the Toyota Production System, and the Lean Enterprise Institute (LEI) describes value stream mapping as the tool Toyota developed under that name. Mike Rother and John Shook's workbook Learning to See (LEI), which received a Shingo Research Prize in 1999, introduced it to a wide audience in manufacturing: map the current state of one product family's flow from order to delivery, design a future state, and plan how to get there. Karen Martin and Mike Osterling's Value Stream Mapping (McGraw-Hill, 2013) adapted the method to office, service and knowledge work, where the work item is a request, a document or a code change and where shared specialists serve many value streams at once. They treat mapping as a management practice: the people who map should include leaders with the authority to change how the work is organised, and the map should end in a plan that gets carried out.

What goes on the map

The map stays coarse. DORA's guide to the capability suggests breaking the value stream into 5 to 15 process blocks and noting, for each, the activity and the team that does it. For software, the stream usually runs from a request or idea to the change running in production for customers. Each block gets three numbers (definitions from DORA's guide and the glossary of TKMG, Karen Martin's firm):

Two summary figures follow from them:

• Activity ratio = total process time ÷ total lead time × 100. Martin and Osterling use it as the summary measure of how well work flows. DLV-214: 2.5 ÷ 22.5 = 11%, so for nearly nine days in ten the change was waiting.
• Rolled first-pass yield = the product of the steps' %C/A: the share of items that get through every step without rework. DLV-214: 80% × 60% = 48%.

Use one unit for both kinds of time. The example counts working days of 8 hours throughout; in calendar time the same lead time is about four and a half weeks and the activity ratio lower still. There is no single standard for drawing the timeline, as Karen Martin notes in a 2014 post: the traditional square wave puts lead times on the peaks and process times in the troughs under the boxes, and she and Osterling later moved to a single line. The diagram splits each step's lead time into its wait, drawn up in red, and its process time, drawn down in blue.

Current state, future state, plan

1. Current state. Map what actually happened, with the real numbers of the day rather than the ones people would like (DORA's guide), ideally by following real work where it is done, the gemba. In office and knowledge work, Martin recommends following a single work item through the stream.
2. Future state. Design how the stream should flow at a set date: TKMG's glossary says future-state maps usually look 3 to 12 months ahead, and DORA's guide gives 6 months to 2 years as an example. Mark each change it needs with a kaizen burst, the jagged icon in LEI's set of mapping symbols, and estimate the new numbers.
3. Plan, then map again. Turn each burst into work with an owner and a date (Martin and Osterling call it the transformation plan), carry it out, and walk the stream again to see what really changed. DORA suggests re-running the exercise on a regular schedule, for example every 6 months, and keeping the maps where everyone can see them.

Putting it into practice

1. Choose one value stream and one kind of work. Acme mapped small changes to the delivery team's services, not "IT" as a whole. Write a short charter first: where the stream starts and ends, the problem (customers wait weeks for small changes), the goal, who takes part and when; LEI's tips stress settling scope before the workshop.
2. Invite the right people. Someone from every step, including the ones outside engineering (product, security, the change board, support), plus a leader who can change the policies that create the queues. Martin calls mapping a team sport and warns against maps drawn by an improvement specialist alone or by a group with no authority to act on them; DORA lists missing authority among the common obstacles.
3. Walk real work. Pick one or two recent changes of the chosen kind and follow them through the ticket history, the pull request, the chat threads and the deploy log, asking the people at each step what happened. Take times from timestamps rather than memory, then check them against the same figures for the last few dozen changes in the ticket system, so that one unusual change doesn't steer the plan.
4. Draw the current state. Paper, a whiteboard or a shared online board is enough; LEI coach Dave LaHote recommends pencil and paper at the place where the work happens over polished diagrams. Add the queues, the timeline and the summary box, and leave out the detail for now.
5. Read the map together. Look for the longest waits, the steps with low %C/A that send work back, handoffs that add nothing, approvals that a check could replace, steps run one after another that could run side by side, and batching such as weekly boards or fortnightly planning.
6. Design the future state and the plan. Pick the few changes that remove the most waiting, estimate the new numbers, and give every kaizen burst an owner, a date and a measure. Try each change as an experiment before rolling it out widely, as LEI's tips advise. At Acme the bursts became four items: policy checks in CI (security and platform teams), self-service test environments from Launchpad (platform team), a standard-change rule under which peer review approves low-risk changes of a known kind (change board), and daily triage with a WIP limit (delivery team).
7. Map again and keep the flow visible. Walk a new change once the plan has landed, and map on a schedule after that. Between maps, a team board with WIP limits and lead times read from the ticket system keeps the waits visible; the Flow Framework, which Mik Kersten introduced in Project to Product (2018), is one way to measure software delivery as flow over time, and Flow Engineering (Steve Pereira and Andrew Davis, 2024) uses five maps in collaborative sessions to turn what they reveal into a roadmap owned by the people doing the work.

Where it fits

• The Three Ways: a value stream map shows the whole flow that the First Way improves; in Gene Kim's description, the First Way looks at the performance of the entire system rather than of one department. In the first edition of The DevOps Handbook (2016), choosing a value stream and making its work visible come in Part II, "Where to Start", before the technical practices of flow.
• DORA Metrics: DORA's change lead time runs from commit to production, only the right-hand end of this map; the map covers the whole journey from request to customer and shows which part of it is slow. DORA lists visibility of work in the value stream among its lean product management capabilities, which its research found to predict better software delivery and organisational performance.
• The fixes in Acme's future state are pages of their own: Policy as Code replaces the security ticket for routine checks, Golden Paths and Platform as a Product turn the environment ticket into self-service, and Continuous Delivery makes the release a pipeline run. DORA's guidance on streamlining change approval backs peer review over an external board, and Trunk-Based Development keeps the batches small.
• Team Topologies: every handoff on the map is a boundary between teams. Stream-aligned teams that own more of the flow, and platform teams that offer services instead of tickets, remove queues instead of shortening them. You Build It, You Run It keeps the release and the pager with the team that builds the service, so no separate release team adds a queue.
• Testing Pyramid: QA's 60% %C/A, the target after Acme's second map, is the kind of rework that faster automated tests earlier in the pipeline reduce.
• CALMS names Lean as one of its five dimensions, and a value stream map is a common way to look at it; SPACE & DevEx measure friction from the developer's side, which a map shows from the work item's side. ITIL 4 covers the service management processes, such as change approval, that often show up on these maps as queues: the map shows what a control costs in lead time, so the future state can keep the control and change how it is done.

When to use it

Value stream mapping pays off where work crosses several teams and nobody can say where the time goes: long lead times for small changes, many handoffs, approvals and tickets, or a plan to buy tools, reorganise teams or build a platform. A map before such an investment shows where it will help; a map after it shows whether it did. It suits regulated settings well, because it shows what each control costs in lead time and leads to doing the control differently rather than dropping it.

It costs more than it returns in some places:

• One small team with few handoffs. A board with WIP limits and lead times from the ticket system already shows the flow; a full workshop adds little.
• Work where every item is different, such as research or a one-off migration. Map a typical item at a coarse level, or follow several and look for the common queues.
• No one will act. Without a leader who can change policies across the steps, the map documents the problem and nothing else.
• Fast-changing flows. A map is a snapshot; where the stream changes every few weeks, continuous flow metrics from the tools serve better than a detailed map.

Adapt it where needed: in regulated environments involve compliance and audit early, so that the future state's controls (peer review records, automated checks, the pipeline's logs) are agreed as evidence; with legacy systems, map the path to production first and remove the largest manual waits; with remote teams, walk the work virtually through the ticket history and recorded handoffs.

Common pitfalls

• Mapping how work should flow. A map drawn from the process wiki or from memory shows the official process (at Acme, 5 steps and 3 days) instead of what happened (8 steps, 22.5 days). Walk real work, with the people who did it, and take the times from the records.
• A map made once and filed. Martin lists beautifully drawn maps with no action behind them among the common failures. Turn the future state into a plan with owners and dates, and map again on a schedule and after each change.
• Improving a step that isn't the bottleneck. Halving QA's 4-hour test run takes the lead time from 22.5 to 22.25 days, about 1%. Remove the biggest waits and the largest sources of rework first; DORA's guide warns that efficiency gains away from the bottlenecks barely move the lead time.
• Adding tools without removing handoffs. A nicer portal for test environment tickets still waits 3 days. Remove the handoff itself (self-service, an automated check, a pre-approved change type) and add tools only where they serve that.
• Too much detail too early. Sixty boxes down to clicks and form fields turn the map into a process map, and the workshop ends before the big waits appear. Martin draws the line here: a value stream map is the strategic, end-to-end view, a process map the detailed, tactical one. Start with 5 to 15 blocks and zoom in only where the map points.
• The wrong people in the room. A map drawn by an improvement specialist alone misses what the steps know, and one drawn by people with no authority over the steps can't change them. Bring both the people who do the work and someone who can change the rules.
• Trusting one change. A single walked change can be unusual. Check its numbers against the ticket history for the same kind of work before choosing what to fix.
• Using the map to blame. The queues belong to the system, not to the team in front of which they form. A map that is used to rank teams teaches them to hide the waits next time.