Lead time

A wider clock than cycle time

Lead time usually starts earlier than cycle time. A feature request can wait for prioritization, remain queued for development, and then spend time in implementation, review, testing, and release. Cycle time might cover only the interval after work starts.

Both measures can be valuable. The mistake is comparing them as if they answer the same question. Write down the start and finish events beside every report.

An illustrative example

Imagine a request approved on March 1 that reaches production on March 15. Its delivery lead time is fourteen elapsed days. If implementation began on March 8, the cycle time from development started to deployment is seven days.

The difference shows where the request waited before work began. It does not prove that the queue was wasteful. Product discovery, dependency decisions, and capacity planning may have been necessary. The measurement gives the team a place to investigate.

Use distributions and work context

Averages can hide requests that remain blocked for months. Inspect percentiles and the individual items in the long tail. Separate planned work, urgent incidents, and large migrations when they follow different paths.

Pair lead time with work in progress and cycle time. A team can reduce the time for completed items while allowing old requests to age in the queue. Looking at both views gives a more honest picture of flow.