Guide
Cycle time, stage by stage.
Cycle time is how long a unit of work takes from being started to being finished. In pull request terms it is most usefully split into four stages — coding, pickup, review and merge-wait — and that split is what turns an unactionable total into a specific thing to fix.
The four stages
Coding runs from the first commit to the pull request being opened. It is the only stage where someone is actively working on the change, and it is almost never the problem.
Pickup runs from the pull request opening to the first review beginning. Nothing happens during it. Nobody is blocked on a decision, no work is in progress; the change simply waits. In most organisations that measure this for the first time, pickup is the largest of the four stages, and it is invariably a surprise.
Review runs from the first review starting to approval. This is the stage everybody assumes is the bottleneck and it usually is not — although it does inflate sharply with pull request size.
Merge-wait runs from approval to the change being merged and deployed. For teams with a release train or a manual approval gate, this can dominate everything else.
Why pickup is the cheapest thing to fix
Pickup time is not a technical problem and does not require a technical solution. It responds to two things: making the queue visible, and agreeing an expectation. A team that sees its unreviewed pull requests in the channel it already reads, and has agreed that reviews start within four hours, will typically halve its pickup time without changing anything about how it writes software.
The related measure worth plotting at the same time is reviewer concentration — how much of the review load sits with how few people. When two people are carrying seventy per cent of reviews, pickup time is not a discipline problem, it is a queueing problem with two servers, and the fix is to widen the queue rather than to ask people to try harder.
Cycle time and lead time
The two terms are used loosely and often interchangeably. DORA’s lead time for changes runs from commit to production. Cycle time in pull request tooling usually means open to merge. The measures overlap substantially and the argument about which is which is not worth having — what matters is stating the boundaries you are using and keeping them stable, so a trend means something.
Where this measure goes wrong
Each of these produces a number that looks reasonable and is not.
Reporting only the total
A total cycle time is a fact, not a lead. The stage split is the part anyone can act on.
Assuming review is the bottleneck
It usually is not. Pickup normally is, and the two get conflated because both involve the review process.
Ignoring pull request size
Size drives review latency more strongly than almost anything else. A size agreement often does more for cycle time than a review-speed target.
Averaging across very different teams
A platform team’s distribution and a front-end team’s distribution are not the same population, and their average describes neither.
Frequently asked questions
What is a good cycle time?
Less useful a question than which stage dominates yours. As orientation, teams in the DORA high band generally show a pull-request cycle time measured in hours to a couple of days. A team with a two-day total that is nearly all pickup has a completely different problem from one with a two-day total that is nearly all review.
How do you reduce pickup time?
Make the queue visible where the team already is — a Slack or Teams channel rather than a dashboard — and agree an explicit expectation for when review starts. Then look at reviewer concentration, because if the queue only has two servers no amount of discipline fixes it.
Is cycle time an individual metric?
No, and using it as one is how organisations lose the trust needed to measure anything. Cycle time is a property of a queueing system. An individual’s cycle time is mostly a description of what else they were asked to do that week.
See cycle time for your own teams
Pacia computes this from your repositories and issue tracker, banded and trended, with a drill-down to the work behind every figure.