Value Stream Mapping for Software: Visualising Flow in Digital Delivery
Value stream mapping was developed by Taiichi Ohno and his colleagues at Toyota as a method for making the waste in a manufacturing process visible. The insight behind it is deceptively simple: the total time it takes to produce a unit — the lead time — is almost always far longer than the sum of the times when work is actually being performed on it. The gap between lead time and processing time is wait time, and wait time is waste. VSM makes that waste visible by mapping each step in the process, the time spent at each step, and the time spent waiting between steps. The same insight applies to software delivery with equal force. A feature request that takes a team ten days to code might take six weeks to reach users — not because the coding was slow, but because it waited three days for code review, four days for a QA environment to become available, two days for QA testing, a week for a deployment approval, and three days in a release queue. The development team is not the constraint. The wait time is.
Defining the unit of value in software
The first step in a software VSM is choosing the right unit of value to map. In manufacturing, the unit is a physical product — a component, a sub-assembly, a finished good. In software delivery, the equivalent is a product backlog item: a user story, a feature, a bug fix, or an improvement that starts as a request and ends as deployed, working software in production. The unit should be representative: a major platform feature and a two-line configuration change will have very different flow paths, so a VSM of a typical backlog item — one of moderate size and complexity — is more informative than mapping an outlier. If the team handles multiple types of work (new features, defects, technical debt, incidents) that follow different paths through the system, a separate VSM for each type is valuable.
How to run a software VSM
Walk the item through the system. Assemble the people who work at each stage of delivery — product owner, developer, code reviewer, QA engineer, release manager — and trace a representative backlog item from the moment it is added to the backlog to the moment it is deployed and verified in production. For each step in the journey, record two things: the process time (how long the item is actively worked on at this step) and the wait time (how long the item sits idle before or after this step). Use a physical whiteboard or a shared digital canvas so the whole team can see the emerging map simultaneously. The act of walking through the system together is as valuable as the map itself — team members who each see only their portion of the process are often surprised by what happens to work before it reaches them and after it leaves them.
Time each step honestly. The instinct in a VSM workshop is to report the best case: code review usually takes a day, QA usually takes two days. Resist this. The purpose of the VSM is to surface the actual experience, not the theoretical throughput. Using historical ticket data — the timestamps recorded in your issue tracker from status change to status change — rather than workshop estimates produces a more accurate picture. Lead time analysis from your issue tracker (plotting the time from ticket creation to deployment for a sample of recent backlog items) provides a data-grounded baseline for the workshop to work from.
Calculate flow efficiency. Flow efficiency is the ratio of process time to total lead time, expressed as a percentage. In manufacturing, a flow efficiency of 5 per cent is common and considered poor. In software delivery, measured flow efficiency of 10 to 20 per cent is typical even in reasonably high-performing teams. If a backlog item spends 20 hours being actively worked on over a total lead time of 25 calendar days (200 hours), the flow efficiency is 10 per cent. 90 per cent of the elapsed time is wait. Seeing this number, calculated from real data, is often the insight that shifts the team's attention from velocity — how fast we code — to flow — how fast value moves through the system.
What software VSMs typically reveal
The consistent findings from software VSM exercises are not where teams expect them. Long wait times at code review are the most common finding: developers complete their work and then the pull request sits waiting for a reviewer to become available. Environment provisioning — waiting for a test environment, a staging deployment, or a production deployment slot — is the second most common bottleneck. Approval gates that are longer than they appear because the approver is not available immediately are the third. What VSMs rarely reveal is that the development itself is the constraint. The coding is usually a small fraction of the total lead time. This is important because most improvement conversations in software teams focus on making development faster — better tooling, better skills, more developers — when the actual bottleneck is almost always in the flow between steps.
Prioritising improvement: wait time before activity time
The VSM produces an immediate improvement agenda. The highest-leverage investments are those that reduce wait time, because wait time is almost always a larger component of lead time than process time. Code review wait time can be reduced by establishing a team norm that pull requests are reviewed within a defined window (four hours, same day), by limiting the size of pull requests so they are faster to review, or by pair programming — which eliminates the review queue entirely by building review into the development process. Environment wait time can be reduced by automating environment provisioning, shifting to on-demand cloud environments, or increasing the frequency of deployment. Approval gate wait time can be reduced by delegating approval authority closer to the work, establishing service-level agreements for approval turnaround, or redesigning the approval process entirely in the case of gates that exist because of historical failures that better automated testing would prevent.
If your delivery teams are committed to shipping quality software but are frustrated by the gap between when work is done and when it reaches users — or if you want to establish value stream mapping as a regular improvement practice rather than a one-off exercise — XNM's program and project delivery advisory works with technology teams and their organisations to identify and remove the flow constraints that determine how fast value reaches customers, regardless of how fast the development team can code.