Why Cycle Time Is the Metric That Matters Most

Nick Morgan, Co-founder6 May 2026 · 4 min read

Most engineering teams track the wrong things. Story points measure effort estimates, not outcomes. Lines of code reward verbosity. Velocity is a planning tool masquerading as a performance metric. None of these tell you whether your team is actually delivering value faster.

Cycle time does.

Cycle time is the elapsed time from when work begins to when it reaches production. For pull requests specifically, it's the time from first commit to merge. This single number captures the combined health of your development workflow: how quickly code gets written, how fast reviews happen, and how smoothly changes flow through your pipeline.

When cycle time is low, it means your feedback loops are tight. Developers get reviews quickly. Merge conflicts are rare because branches are short-lived. Deployments are routine rather than risky events.

When cycle time is high, something in the system is broken. Maybe reviews are bottlenecked. Maybe PRs are too large. Maybe CI is slow. The specific cause varies, but the signal is clear.

Story points are subjective estimates created before work begins. They tell you nothing about what actually happened during delivery. Two teams can complete the same number of story points while operating at completely different levels of effectiveness.

Lines of code penalise refactoring and reward complexity. The best engineering work often reduces the total codebase size.

Velocity (story points per sprint) is useful for capacity planning but actively harmful as a performance target. Teams learn to inflate estimates, and the number becomes meaningless.

Deployment frequency matters, but without cycle time context you can't tell whether frequent deploys reflect genuine flow or just small batches of slow work.

The DORA research programme, now in its tenth year, consistently identifies cycle time (measured as "lead time for changes") as one of four key metrics that predict both software delivery performance and organisational outcomes. Teams with low cycle times deploy more frequently, recover from incidents faster, and report higher job satisfaction.

Poggle's own data across hundreds of engineering teams shows a strong correlation between PR cycle time and broader delivery performance. Teams that maintain cycle times under 24 hours consistently outperform on quality metrics as well, likely because short-lived branches reduce merge complexity and make code review more effective.

If you're not already tracking cycle time, start with PR cycle time. It's observable from your version control system, requires no subjective input, and correlates strongly with overall delivery speed.

Break it into components:

• Time to first review: How long before someone looks at the PR?
• Review time: How long from first review to approval?
• Merge time: How long from approval to merge?

Each component reveals different bottlenecks. Long time-to-first-review suggests a review culture problem. Long review times suggest PRs are too large or reviewers lack context. Long merge times suggest process friction or flaky CI.

Measuring cycle time only helps if you act on it. The most effective teams we've observed share a few common practices:

• Small PRs by default. PRs under 200 lines of changes get reviewed 3x faster than those over 500 lines.
• Review SLAs. Teams that commit to reviewing within 4 hours see dramatically lower cycle times than those without expectations.
• Visible metrics. When cycle time is visible to the whole team, not just managers, improvement happens organically.
• Celebrate progress, not perfection. A team that moves from 72-hour cycle time to 36 hours has made a meaningful improvement, even if they haven't hit an arbitrary target.

Reducing cycle time doesn't just mean shipping faster. It creates a positive feedback loop. Faster reviews mean developers stay in context. Shorter branches mean fewer conflicts. Quicker feedback means bugs are caught earlier, when they're cheaper to fix. Each improvement reinforces the others.

This is why cycle time is worth obsessing over. It's not just a metric. It's a leading indicator of engineering health, and improving it tends to improve everything else along with it.

Nick MorganCo-founder at Poggle