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. In knowledge work, PCE typically lands between 10% and 25%. Read that again: on a normal team, 75 to 90 percent of an item’s lead time is spent waiting for someone to pick it up. The tool color-codes the verdict — 25% and up is green (excellent flow), 10 to 25% is amber (typical, with real improvement available), and below 10% is red (severe queuing; the process is mostly queue). 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. 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.

Customer Onboarding shows the third case: 18% PCE where the longest waits — twelve days for legal sign-off, thirteen for go-live approval — sit on the client’s side of the fence. 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% — a fifth of the lead time 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.