Cycle Time Measurement

Cycle Time Measurement is the practice of tracking the elapsed time between when a team actually begins active work on an item and when that item is completed, isolating the team's execution speed from any time the item spent waiting in a queue before work started. Where Lead Time Measurement captures the full experience of a requester from initial ask to final delivery, cycle time narrows the focus specifically to the portion of that journey during which the team was actively engaged with the item, making it the more internally diagnostic of the two closely related metrics.

What Cycle Time Isolates

The Span of Active Engagement

Cycle time begins at the moment a team member starts working on an item, not when the item was first requested, and ends when the item is fully completed, deliberately excluding any earlier period the item spent waiting in a backlog or queue, which is instead captured separately as queue delay when comparing cycle time against lead time.

A Direct Reflection of Process Execution

Because it excludes pre-work waiting, cycle time responds directly to changes in how the team actually executes work — its workflow design, handoffs, and any bottlenecks within active stages — making it a more targeted diagnostic for process improvement than lead time, which is also influenced by factors like backlog prioritization and intake timing that lie further upstream.

Calculating Cycle Time

Per-Item Calculation

For a single completed item, cycle time is the straightforward difference between its completion timestamp and the timestamp at which active work began.

Distribution-Based Aggregation

As with lead time, cycle times across a set of completed items are typically summarized using percentiles rather than a simple average, since a small number of unusually long-running items can skew a mean well above what most items actually experience, following the same distributional reasoning introduced for lead time.

Cycle Time by Workflow Stage

Breaking Down the Active Period

Because active work typically passes through several distinct stages, such as development, review, and verification, cycle time can be decomposed to show how much of the total active duration was spent in each stage, revealing specifically where within the team's own process delay is concentrated.

Locating Internal Bottlenecks

A stage that consistently accounts for a disproportionate share of total cycle time, relative to the actual effort it typically requires, points directly to a bottleneck the team can investigate and address, offering a level of diagnostic precision that an aggregate cycle time figure alone does not provide.

A Cycle Time Stage Breakdown

A breakdown of this kind, where the review stage accounts for half of total cycle time despite typically requiring less effort than development, directs improvement attention specifically to review capacity or process rather than to development practices that may not actually be the limiting factor.

Using Cycle Time in Forecasting

A Foundation for Probabilistic Forecasting

Historical cycle time data, drawn from a sufficiently large sample of completed items, provides the underlying distribution used in Monte Carlo-style probabilistic forecasting approaches discussed elsewhere in this practice area, since a reliable forecast of how long new work is likely to take depends directly on how consistently and accurately past cycle times have been measured.

Requiring a Stable Process for Reliable Use

Cycle time data is most useful for forecasting when it is drawn from a period during which the team's process was relatively stable, since a significant process change partway through the historical sample mixes two different underlying patterns together, weakening the reliability of any projection built from the combined data.

Common Pitfalls

Conflating Cycle Time With Lead Time

Reporting cycle time while describing it as the full time a stakeholder waited overstates the team's actual responsiveness by omitting any pre-work queue delay, a confusion that the explicit distinction from lead time is specifically meant to prevent.

Measuring Only the Aggregate Without Stage Detail

Tracking a single overall cycle time figure without breaking it down by stage forfeits much of the metric's diagnostic value, leaving the team unable to identify which specific part of its active workflow is actually responsible for extending completion times.

Comparing Cycle Times Across a Changed Process

Drawing conclusions from cycle time trends that span a period during which the team's workflow itself changed significantly conflates the effect of that change with ordinary variation, making it difficult to attribute any observed shift to a specific, identifiable cause.