Guide
Cycle Time, Explained
Cycle time is how long a change takes to travel from first commit to production. Here are its stages - and how to shorten each one without cutting corners.
Cycle time is how long a single change takes to travel from the moment work starts to the moment it runs in production. It is the clearest signal of how much friction sits between an engineer having an idea and a customer feeling the result. When cycle time is short, feedback loops are tight, risk per change is small, and the team can course-correct quickly. When it stretches, work piles up in review queues, context gets lost, and every deploy becomes a bigger, scarier event.
It is easy to confuse cycle time with its cousins. Lead time usually starts earlier - when a request enters the backlog - and includes waiting. Lead time for changes, one of the four DORA metrics, measures from code committed to code deployed. Cycle time typically brackets the active engineering work: first commit on a branch through to merged-and-shipped. The exact boundaries matter less than picking a definition and holding it constant so you can trust the trend.
The point of measuring cycle time is not to rank people. It is to find the stage where changes wait, and to remove that wait without cutting corners on quality or review. This guide breaks cycle time into its stages and shows how to shorten each one honestly.
Define the start and end points precisely
Cycle time is only comparable when everyone measures the same window. Pick concrete, machine-observable events so the metric comes from your git and deploy data rather than from human guesses.
- Start: first commit on the branch, or the moment an issue moves to "In Progress". First commit is the most reliable because it is timestamped and hard to game.
- End: the change reaching production (deploy), not just merge. If you deploy on a cadence rather than per-merge, decide whether to count merge or release and stay consistent.
Write the definition down. A team that measures "merge to deploy" and one that measures "first commit to deploy" are not comparing the same thing, and mixing them quietly poisons the trend.
Break cycle time into its stages
A single number hides where the time actually goes. Decompose cycle time into stages so you can see the bottleneck instead of guessing at it:
- Coding time - first commit to pull request opened. Long here often means batches are too big or requirements were unclear.
- Pickup time - PR opened to first review. This is pure queue time and is frequently the quietest, largest chunk.
- Review time - first review to approval. Reflects review depth, back-and-forth, and reviewer availability.
- Deploy time - approval/merge to production. Reflects your release process, CI duration, and batching.
Once you can see the split, the fix usually becomes obvious. Most teams discover their problem is waiting (pickup and deploy), not working.
Report the median and tail, never the average
Cycle time distributions are heavily skewed: most changes are quick, a few take forever, and those outliers drag the mean into meaninglessness. Report the median as your headline and the p75/p90 to describe the painful tail.
The tail is where the real stories live - the change that sat in review for two weeks, the deploy that was blocked on a flaky test. Improving the tail (p90) usually does more for team morale and predictability than shaving minutes off an already-fast median. Track the distribution over time with a tool like our cycle time calculator rather than eyeballing individual PRs.
Shrink batch size - the single biggest lever
Nearly every cycle-time problem traces back to changes being too large. Big PRs take longer to write, sit longer waiting for a reviewer brave enough to open them, generate more review rounds, and carry more deploy risk. Smaller changes move faster at every single stage.
- Aim for PRs a reviewer can fully understand in one sitting - often a few hundred lines or fewer.
- Split features behind flags so you can merge incomplete-but-safe work continuously.
- Separate refactors from behavior changes so reviewers aren't parsing two things at once.
This is the rare lever that improves speed and quality: smaller diffs get more thorough reviews, not shallower ones. See reducing PR review time for tactics.
Attack queue time, not coding time
The instinct is to make engineers "code faster," but coding is rarely the bottleneck. The wait between PR-open and first-review (pickup time) is invisible, unglamorous, and usually the largest reducible chunk.
- Set an explicit team norm - e.g. "review requests are picked up within a few hours."
- Use review rotations or auto-assignment so PRs never wait for someone to volunteer.
- Cap work-in-progress. When people have fewer open branches, they review sooner instead of context-switching.
- Route reviews by ownership so the right person sees it first instead of it bouncing.
Cutting pickup time costs nothing in quality - it is pure removed waiting.
Automate the path to production
Deploy time balloons when releasing is manual, batched, or risky. The fix is to make shipping boring and continuous rather than an event people schedule around.
- Keep CI fast and reliable - a 40-minute flaky pipeline silently taxes every change. Fix flaky tests instead of re-running them.
- Deploy small and often. Continuous deployment turns "release day" into a non-event and shrinks the blast radius of any one change.
- Invest in fast rollback and feature flags so shipping feels safe, which is what actually lets teams ship frequently.
Speed here comes from confidence, not haste - better tests and safer rollbacks let you go faster precisely because you can undo mistakes cheaply.
Shorten it without cutting corners
Cycle time is trivially gameable if you optimize the number instead of the flow. Rubber-stamped reviews, skipped tests, and merging without deploying all make the metric look better while making the system worse.
- Watch cycle time alongside quality signals - change failure rate, review depth, escaped defects - never in isolation. See measuring code quality.
- Treat cycle time as a diagnostic for the team, not a performance score for individuals.
- Celebrate removed waiting, not removed rigor. If speed came from less review, you borrowed it from future incidents.
Done right, shortening cycle time and raising quality are the same project: small, well-reviewed changes that ship continuously.