Value Stream Mapping

You can't improve a process you haven't measured. A value stream map shows you exactly where time is spent and where it's wasted.

Overview

A value stream map follows one work item — a feature, an onboarding, a bug fix — from request to delivery and splits every hour of its life into two kinds: someone is working on it, or it’s sitting in a queue. Process steps add value; wait steps add lead time. Map your value stream this way and the delivery problem reframes itself: the work isn’t slow — the waiting is. That reframe is the whole reason to run the exercise, and it’s the fastest route we know to a team caring about flow.

PCE and What Counts as Good

The map ends in one number. Process Cycle Efficiency (PCE) is value-add time divided by total lead time, expressed as a percentage. Knowledge work runs low. Michael George, in Lean Six Sigma, sets world class for creative and cognitive work at 25%. Daniel Vacanti puts teams new to managing flow at 5 to 15%. Read that again: at 10%, an item sits untouched for nine of every ten days it spends in your system.

The tool color-codes the verdict. Below 5% is red: severe queuing, and the process is mostly queue. From 5 to 15% is amber: typical, with real improvement available. From 15 to 40% is green: excellent flow. Above 40% the card goes gray and says Check the data. David J. Anderson observed that even adept teams have trouble passing 40%, so a number up there usually means a process step is lying. “Discovery, 2 days” is almost never two days of hands on keyboard. It’s a few hours of work with a queue inside it. Split the queue out into its own wait step and the number comes back to earth. The Flow Metrics Guide covers how PCE relates to the rest of the flow metric family.

A Worked Example

Open Software Feature Delivery, a ten-step pipeline moving one small feature — a CSV export — to production. Add up the process steps: a half hour of grooming, three hours of development, thirty minutes of code review, an hour of QA, thirty minutes to deploy. That’s 5.5 hours of hands-on-keyboard work. Elapsed time: 45 hours. The other 39.5 are queues — 20 hours in the sprint queue, 10 waiting for review, 6 waiting for QA, 2 waiting for a deploy window, 1.5 in post-deploy monitoring. PCE: 5.5 ÷ 45, about 12%. The sprint queue alone is nearly four times all the value-add combined. Run your own arithmetic, then check it against the metric cards.

Now open Bug Fix Hotpath — the same kind of pipeline run as a P1 incident. Five of six hours are value-add: 83% PCE, and the card goes gray. Nobody typed faster on the hotfix. Priority didn’t speed up the work; it deleted the queues. That’s what “expedite” actually is, and it proves the queues were always optional. The card still won’t call it green, because 83% only happens when one item cuts the line and everything behind it waits longer.

Customer Onboarding shows the third case: 18% PCE, green on the card, and still half the lead time sits in two queues on the client’s side of the fence. Twelve days wait on legal sign-off. Thirteen wait on go-live approval. Green isn’t finished. You can’t sprint your way out of that one, but a map turns “onboarding takes forever” into a specific conversation with a specific counterparty about two specific queues.

Running a Mapping Session

We map with the people who touch the work, not the people who supervise it — a developer, a reviewer, QA, ops, and whoever owns the intake. Managers know the official process; the map needs the real one. Pick one real, recently shipped item and reconstruct what actually happened to it, including the embarrassing parts. Keep the granularity at one step per handoff or queue — ten steps, give or take, not forty. And don’t trust memory on wait times: memory shrinks queues. Pull the ticket timestamps. The gap between “review takes a day” and what the timestamps say is usually where the session gets quiet.

Halve the Longest Wait

One experiment is worth running before the session ends. Load Software Feature Delivery and cut the sprint queue from 20 hours to 10. Lead time drops from 45 hours to 35 and PCE climbs to 16%, from amber into green. A fifth of the lead time is gone, and nobody worked a minute faster. Then notice the reverse experiment: optimize the 5.5 hours of work down to 4 and lead time barely moves. Improving the work is an engineering project; deleting a wait is often just a policy decision someone has been avoiding.

The trap to avoid is mapping the ideal process — the one in the onboarding doc — instead of the one your last item actually crawled through. The ideal process always scores well. It also doesn’t exist.

The map’s job is to make one fact undeniable: the feature took a week because it waited a week. What you do about the waiting is a leadership decision, not an engineering one.