Cycle time

The clock keeps running while work waits

Cycle time measures elapsed time, not just hands-on effort. A change that takes two hours to implement but sits in review for three days has a much longer cycle than its implementation effort suggests.

That distinction makes the measure useful for finding delays. It also means a long cycle does not establish that the author worked slowly. The item may have been blocked by an external dependency, a release window, or a decision the team could not make.

An example with explicit boundaries

Suppose an illustrative team defines started as the moment a ticket enters development and finished as its production deployment. A ticket starts Monday at 10 a.m. and ships Thursday at 10 a.m. Its cycle time is 72 elapsed hours.

A second tool might start the clock when the pull request opens on Tuesday. Both reports can be correct under their definitions, yet they describe different portions of the workflow. Document the boundaries alongside the result.

Look beyond the average

A few old items can stretch the mean while most work moves quickly. Inspect the distribution and the individual items behind its long tail. Separate emergency fixes from routine feature work when those classes follow different processes.

Completed-item reports also leave out unfinished work. Pair cycle time with the age of current work in progress so a growing backlog does not disappear from the discussion.