Cycle time

How it is measured

The clock starts when work begins and stops when the change is live. Between those two points, the interval worth splitting into stages:

Coding — first commit to pull request opened. Review wait — pull request opened to first review. Almost always the largest stage, and almost always the one teams are most surprised by. Review — first review to approval. Deploy wait — approval or merge to production.

The total is what gets reported. The breakdown is what gets acted on.

Why the stage breakdown is the whole point

A team told its cycle time is 48 hours learns nothing it can use. The same 48 hours can mean:

• 40 hours of coding and 8 of everything else — changes are too large, which is a pull request size problem
• 40 hours waiting for a first review — a queue problem, usually reviewer capacity or unclear ownership
• 40 hours between approval and production — a deployment problem, usually a release train or a manual gate

Three different diagnoses, three unrelated fixes, one identical number. Review wait is the most common answer, and it is also the cheapest to fix, which is a good reason to look there first.

What it misses

It only counts work that finished. Cycle time is measured on changes that shipped. Work that was abandoned, or is still open after three weeks, is invisible to it — and a team quietly accumulating stalled changes will show a perfectly healthy cycle time right up until someone counts the open branches.

It rewards small batches, which is usually right and sometimes not. Splitting work into smaller changes genuinely lowers cycle time and genuinely helps. Splitting work into smaller changes that individually do nothing also lowers cycle time. The metric cannot tell those apart.

Averages are useless here. Cycle time distributions have long tails, and one two-week change will drag a mean somewhere the team never was. Use the median for the typical experience and p90 for the pain.

It says nothing about whether the change was worth making. A team can halve its cycle time while shipping nothing anybody wanted. Speed metrics need to be read next to something about outcomes, or they quietly become the goal.

How to read it well

Watch the stages, not the total, and watch them as a distribution rather than an average.

Segment before concluding. Bug fixes, features and dependency upgrades have genuinely different natural cycle times, and a shifting mix will move the aggregate without anything about the team changing. A quarter heavy on maintenance work will look faster and mean nothing.

Read it alongside a quality signal — defect rate or change failure rate. Cycle time is trivially improved by reviewing less carefully, and the cost of that shows up somewhere else and later. On its own, a falling cycle time is not evidence of anything good.