Delivery feels slow and leadership wants a productivity initiative. You propose mapping the value stream first. What will you map and what do you expect to find?

Map every step from request to delivered change, with two numbers each

Work time — how long the step actually takes when someone is doing it. Wait time — how long the item sat before the step started, and what it waited on.

Ticket state transitions plus commit, review and deployment timestamps usually contain enough to do this without new instrumentation.

The ratio is the finding

Flow efficiency — work time over elapsed time — is typically fifteen to thirty percent. Most of the elapsed time is queueing, and queues are policy decisions rather than capability problems.

That single number redirects the initiative. A productivity programme aimed at how fast engineers write code is aimed at the smallest block on the chart.

What usually dominates

A release window. An environment queue. Review latency. Approval steps. Each is changeable by decision rather than by capability building, which is why the mapping is worth doing before the initiative is designed.

Include the rework loops

An item that returns from testing to development has traversed the stream twice, and average lead time hides that. Show the loops with their frequency — a ten percent rework rate can dominate the average and points at a quality problem upstream rather than a speed problem downstream.

Act on one queue, then re-measure

Speeding up a step that then waits longer at the next queue changes the total by exactly nothing. Attack the largest wait, re-measure, find the new largest wait.

What to present

The map, the flow efficiency figure, the single largest queue, and what changing it would cost. That is a fundable proposal. "Engineers should move faster" is not.