Map value streams and waiting

A development team says a change takes four hours to build, yet users wait nearly two weeks to see it. These statements describe different parts of the system. **Active work time** is time spent moving the change forward. **Waiting time** is time it remains between steps without progress. **Elapsed time** runs from an agreed entry event to the point at which the change reaches users, or is ready under a clearly named definition. A developer's speed cannot explain the full elapsed time when queues, approvals and release arrangements consume much more time than construction.

A value-stream map makes work, waits and return loops visible. DORA presents the method for understanding software delivery flow and locating constraints; here we apply it to a digital service change. Map the usual route, not the idealized route in a procedure manual. Sample changes of similar size and risk. Record entry and exit for each stage, who decides, and what sends work backward. Combining a tiny emergency fix with a large architecture change and reporting one average would obscure both experiences.

First agree on start and end events. Does measurement begin when someone requests a change or when code is committed? Those are different measures. This lesson measures from acceptance of a routine change request to production, including pre-build waiting. DORA's “change lead time” starts at version-control commit and ends at production deployment; the two numbers should not be compared as though they share a boundary. Also state whether a “day” means calendar time or working time. In the exercise below, each waiting day is treated as eight working hours for a transparent teaching calculation. That simplification is not a real-world delivery promise across weekends and holidays.

| Stage | Active work | Wait before work | Observed reason | | --- | ---: | ---: | --- | | Triage | 0.5 hour | 2 days | Weekly triage meeting | | Build and local test | 4 hours | 1 day | Team capacity | | Change review | 1 hour | 4 days | Two-reviewer queue | | Production release | 0.5 hour | 2 days | Grouped release window |

Active work totals 0.5 + 4 + 1 + 0.5 = 6 hours. Waiting totals 2 + 1 + 4 + 2 = 9 working days, or 72 hours under the stated eight-hour convention. The illustrated elapsed time is 78 working hours, equal to 9.75 working-day equivalents. **Active-work share of elapsed time** is 6 / 78, approximately 7.7%. That ratio describes this path and boundary; it is not a universal target. Some waiting may allow an independent check or a safe release window. It does, however, direct attention to the long waits instead of rewarding a one-hour reduction in coding time as the main transformation result.

There is a further observation: 12 changes arrive at review each week, while reviewers can finish 10 at the required standard. If demand and capacity remain constant, unfinished review work grows by two changes per week. This does not prove every individual change waits exactly four days; prioritization and change size affect each wait. It does show that the queue cannot stabilize unaided. Faster building may deliver work to review a little earlier but cannot increase review capacity. Distinguish a temporary delay, perhaps caused by an incident, from a sustained capacity constraint in which arrivals repeatedly exceed completions.

Compare two interventions. Option A buys a code-generation tool that saves one build hour per change. If all waits stay constant, active work falls to five hours and the illustrated elapsed time to 77 hours; the theoretical path improvement is one hour while review remains overloaded. Option B trains an additional qualified reviewer while preserving test requirements and any necessary separation of duties. In a bounded trial, review capacity rises from 10 to 14 changes per week. With 12 new arrivals, the backlog could then fall by two a week, but the new wait is unknown until observed, and the constraint might move to release. Trial B first because the evidence points to review. Track review defects returned to developers and review quality as well as speed. Do not delete a required control merely to shorten a chart.

Define the trial carefully. For four weeks of comparable routine changes, record entry and exit at triage, build, review and release; count returns to an earlier stage; classify defects caught in review; and mark releases that caused a failure needing immediate intervention. After adding review capacity, compare the distribution of review waits, not just the average: easy changes may improve while complex ones wait longer. Monitor incoming demand. If it climbs from 12 to 16 a week, capacity of 14 will not stabilize the queue. The team should stop expansion of the trial if decision quality worsens or an approved separation-of-duties constraint cannot be maintained.

Finding the current constraint does not prove the other stages are sound. The grouped release window adds two days. A safer and more frequent release capability might reduce that delay; alternatively, the window may support verification and communication in a high-risk environment. Investigate its purpose after dealing with the review queue rather than assuming every wait is waste. Active-work share can rise when wait is cut, but also when useless work is added. Tie the map back to a user outcome and change correctness. Use it to frame a falsifiable improvement experiment, not to rank teams on one percentage.