A delivery problem rarely belongs to one metric. Long cycle time may begin with variable demand or a saturated review queue, with excess WIP compounding either one. The map follows those relationships from the request entering the system to the value users receive.
The operating model
The flow system
Demand
What arrives and why it matters
System design
How work is governed and where it slows
Flow mechanics
Why queues form and work ages
Measures
The evidence the system produces
Outcomes
What users and the organisation receive
Change
How the system learns and improves
Demand enters with a shape
A software team receives features and production incidents. Each work item carries a route and urgency. Work-item types make those differences explicit. Cost of delay adds the expected value and gives the team an economic reason for choosing one item ahead of another.
The options backlog can hold many requests without slowing delivery. The cycle-time clock starts when the team commits and allows an item into the delivery system. That commitment turns an option into WIP.
System design shapes the route
STATIK starts with customer demand and works inward to a service design. The resulting workflow determines where a ticket waits and what policy governs its next move.
Communication structure affects the same route. A change crossing several team boundaries carries more hand-offs and review queues. Somewhere in that network, one stage has less effective capacity than the demand placed on it. That stage is the constraint, and its rate sets the ceiling for delivery.
Queues carry the consequences
High utilisation leaves little capacity for an unexpected incident or a large pull request. Variability turns that lack of room into queues. Kingman’s formula describes how waiting rises as utilisation approaches full capacity.
Multitasking adds another source of delay. Starting a new ticket moves attention away from work already in progress, leaving both items to age. WIP rises while the rate of completed work may stay flat.
WIP, throughput, and cycle time move together
Little’s Law connects the three operating measures: WIP equals throughput multiplied by cycle time. A team completing five tickets per week with 20 items in progress has an average cycle time of four weeks.
The constraint limits how far throughput can rise. Reducing WIP is often the faster lever because it does not require more constraint capacity. Fewer active tickets means less waiting between development and review.
Measures reveal the system
A cumulative flow diagram shows queues forming as the distance between stage lines widens. Historical throughput and cycle-time distributions provide the evidence for probabilistic forecasts.
Forecast quality depends on a stable view of the work. Mixing hotfixes with features hides the characteristic pace of each type. A forecast built from comparable finished items gives a delivery range the team can defend.
Delivery timing becomes an economic result
A feature begins generating value after release. Longer cycle time delays that return even when the team reports the same eventual throughput. Value-delivery measures make the timing cost visible.
Throughput accounting brings the constraint into financial decisions. Work consuming scarce review capacity needs enough expected return to justify that time. Work using spare capacity elsewhere can be valuable without reducing system output.
Improvement changes the system before it changes the result
A new WIP policy or review practice can lower performance while the team learns it. The J-curve makes that temporary dip visible. Leaders need enough evidence and patience to keep the change alive until the new process begins to outperform the old one.
The map above is a loop. Delivery outcomes create new information about demand and capability. The team uses that evidence to adjust the route through policies and capacity.