How to Eliminate Waste in Software Development: A Value Stream Mapping Guide

This guide shows how to find the waste in your own software delivery and remove the biggest piece of it, using a value stream map built from real work items. You’ll get a mapping template, the arithmetic for lead time and flow efficiency, a checklist of Lean’s seven wastes, and a way to test whether your fix worked. For the principles behind it, and why most waste is structural rather than laziness, read Lean software development explained first.

One team runs through every step. Seven developers and two testers own the checkout of an online grocery business. They feel busy all the time, yet a one-line change to the delivery-slot screen takes about six weeks to reach customers. Nobody can say where the time goes.

Who this is for

• Team leads and Scrum Masters whose team is busy but slow to deliver.
• Engineering managers who want to know where delivery time goes before buying tools or adding people.
• Anyone who has read about Lean and wants a first practical exercise.

Before you start

• Access to the history of real work. Your tracker, pull requests and release log for the last few weeks. Memory is not good enough; people remember the work, not the waiting.
• Two hours with the people who do the work. Developers, testers and whoever releases. Managers alone will draw the process as it’s supposed to be.
• Agreement to change one thing. The map is only worth drawing if the team can act on what it shows.

Step 1: Choose one value stream and fix its start and end

A value stream is every step a piece of work goes through, from a customer’s need to the moment the customer can use the result. Pick one stream, usually one type of work for one team, and write down exactly where it starts and ends.

Start as close to the customer’s request as your data allows: usually the day the request was accepted onto the backlog, not the day the team started work on it. The wait in the backlog is often the biggest delay of all. End at “a customer can use it”, not “merged” or “done in the sprint”.

In the scenario: the stream is “small changes to checkout”. It starts when the product owner accepts a request onto the product backlog and ends when the change is live for all customers.

Step 2: Trace real items, not the official process

Take the last five to ten items that went all the way through. For each one, use the tracker history, the pull request and the release log to find the date it entered each step and the date it left. This is Lean’s “go and see”: look at what happened, not at the process diagram.

Where dates are missing, ask the person who did the work. Note anything that went backwards, like a bug sent back from testing.

In the scenario: the team traces six recent changes. Two went back from testing to development once each. One waited an extra week because its developer was pulled onto an incident.

Step 3: Draw the map with process time and wait time

List the steps left to right. For each one, record two numbers, averaged over the items you traced:

• Process time: time someone was actually working on the item.
• Wait time: time the item sat in a queue before that step started.

Use working days. Keep the map to five to ten steps. If it needs more, the stream is too broad.

In the scenario:

Step	Wait before (days)	Process (days)
Refinement	5	0.5
Development	4	3
Code review	2	0.5
Testing	3	1
Release	9	0.5

Step 4: Calculate lead time and flow efficiency

Add up the totals:

• Total process time = sum of process times.
• Lead time = total process time + total wait time.
• Flow efficiency = total process time ÷ lead time.

Flow efficiency is the share of the lead time in which anyone was working on the item. In most teams it’s well below half, which means the fastest way to deliver sooner is usually to cut waiting, not to work faster.

In the scenario: process time is 5.5 days and waiting is 23 days, so lead time is 28.5 days. Flow efficiency is 5.5 ÷ 28.5, about 19%. For four-fifths of those six weeks, the change is just waiting.

Step 5: Name the waste

Go through the map with the seven wastes of software development from the Poppendiecks’ “Implementing Lean Software Development” and mark where each one shows up:

1. Partially done work: finished but not released.
2. Extra features: built but not needed.
3. Relearning: rediscovering something already known.
4. Handoffs: work passed between people, losing knowledge each time.
5. Task switching: people splitting attention across too many items.
6. Delays: waiting for a person, a decision or an environment.
7. Defects: work that has to be redone.

In the scenario: the 9-day wait before release is partially done work: tested changes sit until the monthly release. The 3-day wait before testing and the two bugs sent back are handoffs and defects. Developers coming back to a bug three days later is relearning.

Step 6: Fix the biggest wait you can control

Pick the single largest wait time that the team can change on its own, and design one countermeasure for it. Write it as an experiment: what you’ll change, what you expect to happen, and when you’ll measure.

Don’t try to fix everything. Fixing several things at once makes it impossible to know which change worked.

In the scenario: the biggest wait is the 9 days before release. The cause is the monthly release window, which exists because releases used to break things. The team automates the deployment and its checks, and releases each change once it has passed testing. The experiment: “We expect release wait to drop below 2 days. We’ll re-measure in six weeks.”

Step 7: Measure again

After four to six weeks, trace another set of recent items through the same map and recalculate. Compare lead time and flow efficiency with the first map. If the number didn’t move, find out why before trying something else.

In the scenario: release wait falls from 9 days to 1. Total waiting drops to 15 days, lead time to 20.5 days, and flow efficiency rises to about 27%. A one-line change now reaches customers eight working days sooner. The next biggest wait is refinement, which needs the product owner, so that becomes the next experiment.

Step 8: Make it a habit

Redraw the map every quarter, or whenever the team’s way of working changes. Keep the old maps; the trend is what shows whether the waste is going down. Bring the current map to retrospectives, so improvement ideas are aimed at the biggest wait rather than whatever annoyed people that week.

In the scenario: the team adds lead time to its monthly review alongside its other measures. At the next quarterly map, it checks whether the refinement experiment with the product owner worked, and picks the next biggest wait.

Copy-paste templates

Value stream map

Value stream: _______________
Starts: _____________________
Ends: _______________________
Items traced: ____
From: ________ To: ________

| Step        | Wait | Process | Sent back |
|-------------|------|---------|-----------|
| Refinement  | 5    | 0.5     |           |
| Development | 4    | 3       |           |
| Code review | 2    | 0.5     |           |
| Testing     | 3    | 1       | 2 of 6    |
| Release     | 9    | 0.5     |           |
(days; wait = time queued
before the step starts)

Process time:    5.5 days
Wait time:       23 days
Lead time:       5.5 + 23
                 = 28.5 days
Flow efficiency: 5.5 / 28.5
                 = 19%

Seven wastes checklist

Tick what you see on the map,
and note the step:

[ ] Partially done work
    Finished, not yet released
[ ] Extra features
    Not asked for, or "just in
    case"
[ ] Relearning
    Rediscovering context or
    decisions
[ ] Handoffs
    Work passed between people
    or teams
[ ] Task switching
    People on several items at
    once
[ ] Delays
    Waiting for a person,
    approval or environment
[ ] Defects
    Sent back, or fixed after
    release

Improvement experiment

Biggest wait we control:
_____________________________
Current wait: ____ days
Cause:
_____________________________
Change we'll make:
_____________________________
We expect the wait to drop
from ____ to ____ days
Measure again on: __________
Owner: _____________________

Result
Lead time: ____ -> ____ days
Flow efficiency:
____% -> ____%
Keep / adjust / drop: _______

Common mistakes

Mapping the official process. The map shows how work is supposed to flow, so the waits are missing. Fix: trace real items using dates from your tools.

Measuring only process time. The team speeds up development, and lead time barely moves because the waiting is elsewhere. Fix: measure waits first; they’re usually most of the lead time.

Fixing everything at once. Five changes go in together and nobody can tell which one helped. Fix: one experiment at a time, on the biggest wait the team controls.

Picking a wait you can’t change. The team targets a delay owned by another department and stalls. Fix: start with waits inside the team’s control, and take the map to the other team as evidence for the next one.

Calling all coordination waste. Code review and testing are treated as waste and cut. Fix: they’re necessary work; the waste is the waiting before them and the defects that slip through.

A one-off workshop. The map is drawn once and filed. Fix: re-measure after every experiment and redraw the map quarterly.

You’re done when

• One value stream is chosen, with a clear start and an end of “a customer can use it”
• Five or more real items have been traced using dates from your tools
• The map shows wait time and process time for every step
• Lead time and flow efficiency are calculated
• The seven wastes are marked on the map
• One experiment targets the biggest wait the team controls
• The map has been measured again after the experiment
• A date is set for the next map