What is cycle time in software (and how to reduce it)?
Cycle time is how long a piece of work takes from started to shipped. Here's what it measures, why it's the most useful engineering metric, and practical ways to reduce it.
Cycle time in software is how long a piece of work takes from the moment someone starts it to the moment it ships to production (or 'done'). It's the single most useful engineering flow metric because it captures the whole delivery pipeline — coding, review, testing, deploy — in one number. Rising cycle time is an early warning that something is stuck.
How is cycle time measured?
Track it per work item as done-time minus started-time, then look at the team's average and p90 (the slowest 10% often reveal the real bottleneck). Measure in business hours, not wall-clock, so a ticket that sits over a weekend isn't unfairly penalised. Watch the trend, not a single number.
What makes cycle time go up?
- Slow code review — PRs waiting for a first look.
- Large PRs — big changes are harder and slower to review.
- Flaky or slow CI — deploys blocked on the pipeline.
- Scope creep — tickets that grow after they start.
- Rework — QA bounce-backs and reopens sending work backwards.
How do you reduce cycle time?
Shrink PRs, review faster (a team norm of first-review-within-a-few-hours does more than anything), keep tickets small and well-scoped, and fix the flaky tests. You can only improve what you can see, so surface cycle time (and its p90) somewhere the team looks — without turning it into a stick to beat people with.
truelo shows team cycle time (avg and p90), throughput and reopens, pulled from Jira or Linear, right in Slack.
See it work in your Slack in five minutes.
Add to Slack