Cycle time

Most engineering teams think they have a delivery problem when they actually have a visibility problem. Cycle time, the total time it takes to move a unit of work from active development to production, is one of the clearest signals of how efficiently your delivery pipeline actually runs. When squads don't measure it, slow releases feel like a people problem rather than a process problem. This page covers the definition of cycle time, how to measure it, what good looks like, how to improve it, and how DevStats surfaces it automatically.

• Cycle time is the elapsed time between when a unit of work enters active development and when it reaches production. It matters because it directly reflects the speed and health of your delivery process, not just how busy your squad is.
• Cycle time is calculated as: Cycle Time = Completion Date minus Start Date, measured per work item. According to DORA's 2023 State of DevOps Report, elite-performing teams achieve a lead time for changes (a closely related measure) of less than one day, while low performers take between one week and one month.
• The most common mistake teams make is confusing a long cycle time with a productivity problem and pushing for more output. Long cycle time usually signals a process bottleneck, such as slow code review, large PR sizes, or blocked handoffs, not a lack of effort from individual players.
• DevStats tracks cycle time automatically by connecting to your Git provider and issue tracker, with benchmarks against 1,000+ engineering teams. You can see your PR cycle time breakdown and issue cycle time in a single view. Start a free trial to see your numbers in under two minutes.

Cycle time definition

Cycle time is the total elapsed time from when active work begins on a task to when that work is delivered to production. It measures the speed of your delivery process, not the time a ticket sits waiting to be picked up.

For software teams, cycle time is typically calculated as: Cycle Time = Delivery Date minus Work Start Date, measured per pull request or issue. It draws on data from your Git provider and issue tracker. When cycle time is long, it signals friction somewhere in the pipeline: review queues, deployment bottlenecks, or unclear acceptance criteria. Shorter cycle times correlate with faster customer feedback loops and more predictable release schedules, both of which matter to business stakeholders, not just engineering.

Why cycle time matters for engineering teams

When squads don't track cycle time, delivery slowdowns stay invisible until they become missed sprint commitments or delayed product launches. A team can look busy while work piles up in review, sits blocked on a dependency, or waits days for a deployment slot. Without the data, you're managing by intuition rather than signal.

Cycle time connects directly to the KPIs engineering leaders are accountable for: on-time delivery, release predictability, and team throughput. It also ties into the DORA framework, where "lead time for changes" is one of four core delivery performance metrics. Teams that actively monitor cycle time can spot where work stalls before it becomes a pattern. If you're looking at DORA metrics as part of your engineering health program, cycle time is one of the first places to start, and you can explore how DevStats surfaces these signals on the DORA metrics feature page.

Measurement is the starting point. Once you know where time is actually going, you can make an informed decision about what to change. The data doesn't fix anything; you do.

How to measure cycle time

Cycle time starts when a player first commits code or moves a ticket to "in progress" and ends when that work is deployed to production. You need two data sources at minimum: your Git provider (GitHub, GitLab, Bitbucket) and your issue tracker (Jira, Linear, GitHub Issues). If you want to include deployment confirmation, you'll also need your CI/CD pipeline data.

The benchmarks below are informed by DORA's 2023 State of DevOps Report for lead time for changes, which is the closest published benchmark to cycle time. Exact cycle time benchmarks vary by team size, codebase complexity, and release model, so use these as directional reference points rather than hard targets. DevStats provides peer benchmarks based on comparable teams so you can calibrate against relevant context.

For a more granular view, break cycle time into its sub-stages: coding time, code review time, and deployment time. That breakdown tells you exactly where time is being lost.

Cycle time in practice: a real example

A VP of Engineering at a 40-person SaaS company noticed that sprint velocity looked stable but the team kept missing release targets. She pulled the cycle time data and found that PRs were sitting in review for an average of four days before getting a first response. The coding phase was fast. The bottleneck was entirely in the review queue.

She made one structural change: the squad agreed to a 24-hour first-review SLA, and she moved code review into the daily standup as a standing agenda item. Over the next two sprints, average cycle time dropped by roughly 40%. She tracked PR cycle time and sprint completion rates week over week to confirm the improvement held. The data told her where to look. She decided what to do about it.

How to improve cycle time

1. Reduce PR size. Large pull requests take longer to review and longer to merge safely. Set a team norm for PR size, typically under 400 lines of changed code, and watch review time drop. Track average PR size alongside PR cycle time to see the correlation in your own data.

2. Set a review SLA and enforce it. If PRs sit unreviewed for more than 24 hours, cycle time inflates regardless of how fast players write code. Agree on a first-response window and make review queue depth visible in standups.

3. Audit your deployment pipeline. If deployment itself takes hours or requires manual steps, cycle time will be long even when the code is ready. Identify the slowest stage in your CI/CD pipeline and target it for automation. DevStats surfaces deployment frequency and speed so you can see whether deployment is the constraint.

4. Break down large issues before sprint start. Tickets that are too broad create long cycle times because players have to interpret scope mid-sprint. Improving planning accuracy upstream reduces ambiguity that inflates cycle time downstream.

5. Watch for blocked work patterns. If cycle time is long but coding time is short, the time is being lost to waiting, not working. Use an activity heatmap to identify when and where work stalls across the week.

Cycle time vs. lead time

Cycle time and lead time are related but measure different windows. Lead time starts when a request is created (before work begins). Cycle time starts when active work begins. Confusing the two leads to misdiagnosis: a long lead time might mean a prioritization problem, while a long cycle time means a delivery process problem.

Use lead time when reporting to stakeholders on overall responsiveness. Use cycle time when diagnosing what's slowing down your squad's delivery process.