Software cycle time

Most engineering leaders know their sprints are slipping, but they cannot pinpoint where time is actually going. Software cycle time is the elapsed time from when a developer starts active work on an item to when that work ships to production. Tracking it gives your squad a clear signal about delivery speed and where work stalls. This page covers the definition, how to measure it, industry benchmarks, how to improve it, and how DevStats surfaces it automatically.

Key takeaways

• Software cycle time is the duration between a developer beginning active work on a task and that task reaching production. It is a direct measure of your delivery pipeline's efficiency, and teams that track it consistently can identify bottlenecks before they compound into missed release dates or eroded stakeholder trust.
• Cycle time is calculated as the time elapsed from work-in-progress start to production deployment. According to the DORA State of DevOps 2023 report, elite-performing teams achieve a change lead time (a closely related metric) of less than one day, while low performers can take more than six months. Your cycle time benchmark will vary by team size and release model, but directionally, shorter is better.
• The most common mistake teams make is conflating cycle time with lead time. Cycle time starts when active development begins, not when a ticket is created or first requested. Measuring from ticket creation inflates the number with queue wait time, making it harder to diagnose whether the problem is in the work itself or in prioritization and planning upstream.
• DevStats tracks software cycle time automatically by connecting to your Git provider and issue tracker, with benchmarks against 1,000+ engineering teams. You can see your squad's numbers broken down by stage, including coding, review, and deployment, without any manual data collection. Start a free trial to see your numbers in under two minutes.

Software cycle time definition

Software cycle time is the total elapsed time from when a developer begins active work on a task to when that work is deployed to production. It excludes time spent waiting in a backlog before work starts. In plain terms: it tells you how long it takes your team to finish something once they have started it.

The formula is straightforward: Software Cycle Time = Deployment Timestamp minus Work-Started Timestamp. Data sources typically include your Git provider (for first commit or branch creation), your issue tracker (for status transitions to "in progress"), and your CI/CD pipeline (for deployment timestamps). You can track this at the pull request level using PR cycle time or at the issue level using issue cycle time, depending on the granularity you need. When cycle time shrinks, your team delivers value to customers faster and your business can respond to market feedback in tighter loops.

Why software cycle time matters for engineering teams

When squads do not track software cycle time, bottlenecks stay invisible. Work piles up in review, deployments get batched into risky releases, and sprint commitments slip without anyone knowing exactly why. By the time the problem surfaces in a retrospective, the root cause is already two or three sprints old. Engineering leaders who measure cycle time can see the stall points in real time, before they affect roadmap delivery or team morale.

Cycle time connects directly to the KPIs that matter most to your stakeholders: on-time delivery, release predictability, and engineering throughput. It is also a core signal in the DORA framework, which links delivery performance to organizational outcomes like revenue and employee retention. Teams that ship in smaller, faster batches tend to have lower change failure rates and recover from incidents more quickly. You can see how cycle time fits alongside deployment frequency and other DORA metrics on the DevStats DORA metrics feature page, which surfaces all four key measures in one view.

Measurement is the starting point, not the finish line. Once you have reliable cycle time data, you as the engineering leader decide what it means for your team and what to change.

How to measure software cycle time

To calculate software cycle time accurately, you need three data points: when active work began, when the code was merged, and when the deployment reached production. Most teams pull the "work started" signal from either the first commit on a branch or the timestamp when an issue moved to "in progress" in their issue tracker. The end point is the production deployment timestamp from your CI/CD pipeline. Combining these sources gives you a full picture of where time is spent across coding, code review, and deployment.

No single published benchmark covers software cycle time universally, since it varies by team size, codebase complexity, and release model. The DORA State of DevOps 2023 report uses "change lead time" as a proxy, which includes cycle time as a major component. The table below uses DORA's lead time tiers as a directional guide. You can compare your squad's numbers against peers using DevStats benchmarks, which draw on data from over 1,000 engineering teams.

Source: DORA State of DevOps 2023. Note that these tiers apply to change lead time as defined by DORA; your cycle time measurement may differ depending on where you set the start boundary.

Software cycle time in practice: a real example

A VP of Engineering at a 40-person SaaS company noticed that sprint commitments were consistently being met at around 70% completion. She pulled cycle time data segmented by stage and found that coding time was stable at roughly one day per ticket, but the review-to-merge stage was averaging four days. The data showed that PRs were sitting unreviewed for long stretches, not because players were slow reviewers, but because review requests were landing during high-focus coding blocks with no clear ownership rotation.

She introduced a squad norm: every open PR older than 24 hours gets a named reviewer assigned in the daily standup. She also set a target to bring median PR cycle time below two days within the next two sprints. Four weeks later, cycle time had dropped and sprint completion rate climbed. The data told her where to look. She decided what to do about it.

How to improve software cycle time

1. Reduce PR size. Large pull requests take longer to review and are more likely to generate back-and-forth. Set a squad norm for PR size, such as under 400 lines of changed code, and track whether smaller PRs correlate with faster merge times. Watch your throughput alongside PR size to confirm that smaller batches are also increasing the volume of work shipped.
2. Set explicit review SLAs. If PRs sit unreviewed for more than 24 hours, cycle time inflates without anyone writing a single line of code. Agree on a review response window as a squad and surface stale PRs in your daily standup. This is a process change, not a performance judgment.
3. Automate your deployment pipeline. Manual deployment steps add hours or days to cycle time after code is already merged. Audit your deployment pipeline for manual gates and replace them with automated checks where possible. The goal is to make deploying boring and routine.
4. Break work into smaller issues. If issues routinely take more than a week to complete, the work is probably too large. Decompose epics into tasks that a player can ship in one to two days. This also makes planning accuracy easier to improve, since smaller items are easier to estimate.
5. Review your sprint allocation. Cycle time often inflates when players are context-switching across too many parallel workstreams. Use allocation data to see how your squad's time is distributed and whether unplanned work is crowding out sprint commitments.

Software cycle time vs. lead time

Software cycle time and lead time are related but measure different windows of your delivery process. Cycle time starts when active development begins. Lead time starts when a request or ticket is first created, including all the time it spends waiting in a backlog before anyone touches it.

Use cycle time to find friction inside your delivery process and lead time to understand the full experience from your customer's or stakeholder's perspective. Both metrics together give you a complete picture of where time is lost.