Most engineering leaders can tell you their sprint velocity. Far fewer can tell you exactly how long it takes a piece of work to move from active development to deployed code. Development cycle time measures that gap precisely, and when it's invisible, bottlenecks accumulate silently across your delivery pipeline. Development cycle time is the elapsed time between when a player starts active work on a task and when that work is merged or deployed. Tracking it gives you a concrete signal about the health of your delivery process, not just how busy your squad is. This page covers the definition, how to measure it, industry benchmarks, a real-world example, and how to improve it.
Key takeaways
- Development cycle time measures how long it takes a unit of work to move from active development to completion. It matters because it makes the speed of your delivery process visible, turning a vague sense of "things feel slow" into a number you can act on.
- Calculate development cycle time by measuring the elapsed time from when a player begins active work (first commit or issue status change to "in progress") to when the work is merged or deployed. Elite engineering squads typically achieve cycle times under one day for individual pull requests, based on DORA State of DevOps 2023 benchmarks for change lead time.
- The most common mistake teams make is confusing a short cycle time with high productivity. A player who rushes through code review or skips adequate testing can compress cycle time while creating downstream rework. Cycle time must be read alongside quality indicators like defect rates and review depth.
- DevStats tracks development cycle time automatically by connecting to your Git provider and issue tracker, with benchmarks against 1,000+ engineering teams. Start a free trial to see your numbers in under two minutes.
Development cycle time definition
Development cycle time is the total elapsed time from when a developer begins active work on a task to when that work is finished and ready for production. It measures how fast your delivery process moves once work is in flight, not how long it sat waiting to be picked up.
Technically, it is calculated as: Development cycle time = timestamp of completion (merge or deploy) minus timestamp of work start (first commit or "in progress" status). Most squads measure this at two levels: the PR cycle time for individual pull requests and the issue cycle time for full feature or bug tickets. When cycle time is long, engineering investment takes longer to reach customers, which directly affects your ability to respond to market feedback and ship commitments on time.
Why development cycle time matters for engineering teams
Without visibility into development cycle time, slow delivery looks like a capacity problem when it is often a flow problem. Squads miss sprint commitments, stakeholders lose confidence, and engineering leaders make headcount decisions based on incomplete data. The real culprit is frequently waiting time buried inside the process: PRs sitting unreviewed, tickets blocked on dependencies, or work bouncing back from code review repeatedly.
Development cycle time connects directly to the KPIs engineering leaders are accountable for: on-time delivery, throughput, and the ability to make credible commitments to product and business stakeholders. It also maps cleanly to the DORA framework's "lead time for changes" metric, one of the four core indicators of software delivery performance. You can see how your squad's cycle time compares to industry peers using DevStats's DORA metrics feature, which surfaces these signals automatically from your existing tools.
Measurement is the starting point, not the finish line. Once you can see where time is going, you are in a position to make informed decisions about where to intervene.
How to measure development cycle time
To calculate development cycle time, you need two timestamps: when work started and when it ended. "Work started" is typically the first commit pushed to a branch or the moment a ticket moves to "in progress" in your issue tracker. "Work ended" is the merge to main or the deployment event. You need data from your Git provider (GitHub, GitLab, Bitbucket) and your issue tracker (Jira, Linear, GitHub Issues) to get accurate numbers. For squads running continuous deployment, connecting your CI/CD pipeline via your deploy data gives you the most precise end timestamp.
No single published benchmark covers "development cycle time" as a standalone metric across all team types. The closest published reference is DORA's "lead time for changes," which includes review and deploy time. Benchmarks vary by team size, codebase complexity, and release model, so use these as directional signals, not hard targets. DevStats's benchmarks feature lets you compare your numbers against squads with similar profiles.
| Performance level | Development cycle time benchmark | What it signals |
|---|---|---|
| Elite | Less than 1 day (per PR or task) | Work moves through the pipeline with minimal waiting; review and integration friction is low |
| High | 1 to 3 days | Healthy flow with occasional review delays; manageable for most growth-stage squads |
| Medium | 3 to 7 days | Visible friction in review, integration, or task scoping; worth investigating the cause |
| Low | More than 7 days | Significant bottlenecks in the process; delivery predictability is at risk |
Source: Directional ranges informed by DORA State of DevOps 2023 lead time for changes benchmarks. Exact thresholds vary by team context.
Development cycle time in practice: a real example
A VP of Engineering at a 40-person SaaS company noticed her squad was consistently missing sprint commitments despite high activity levels. She pulled cycle time data and found that the median PR cycle time was six days, with most of the elapsed time concentrated in the review stage. PRs were being opened but sitting unreviewed for two to three days before anyone picked them up. The squad was not slow at writing code. The process of getting code reviewed and merged was the constraint.
She introduced a squad norm: all open PRs get a first review within 24 hours, and any PR open for more than two days gets flagged in the daily standup. She tracked collaboration patterns and PR cycle time week over week to evaluate whether the change was holding. Within three sprints, median cycle time dropped to under two days and sprint completion rates improved. The intervention was hers. The data told her where to look.
How to improve development cycle time
- Set a PR size limit and enforce it. Large PRs are the single biggest driver of long cycle times. When a PR touches more than 400 lines, review time increases non-linearly. Set a squad norm of 200 to 400 lines per PR and break larger features into stacked PRs. Watch your PR cycle time distribution to confirm smaller PRs are moving faster.
- Establish explicit review SLAs. Unreviewed PRs are idle work in progress. Define a squad agreement: first review within 24 hours, follow-up within 4 hours of a re-request. Make it a process expectation, not a personal one. If review lag persists, check your activity heatmap to see whether review activity is clustered in ways that create natural delays.
- Reduce work in progress limits per player. When players carry three or more active tasks simultaneously, context switching inflates cycle time on all of them. Limit active work to one or two items per player and use sprint planning data to spot over-allocation before the sprint starts.
- Audit your definition of "done" at the task level. Cycle time blows out when tasks are scoped ambiguously and players discover scope mid-flight. Tighter acceptance criteria at ticket creation reduces rework cycles. Use planning accuracy data to identify which ticket types consistently run long, then refine how those tickets are written.
- Automate integration and test feedback. Manual QA gates and slow CI pipelines add waiting time that shows up in cycle time but has nothing to do with development speed. If your pipeline takes more than 15 minutes to return a result, that is a process improvement target. DevStats surfaces speed metrics that can help you see where automated steps are adding drag.
Development cycle time vs. lead time for changes
Development cycle time and lead time for changes are related but measure different spans of the delivery process. Lead time for changes (a DORA metric) starts from the moment work is committed to a backlog or a code commit is made and ends at deployment to production. Development cycle time typically starts later, at the point of active work, and may or may not include deployment depending on how your team defines it.
| Development cycle time | Lead time for changes | |
|---|---|---|
| Measures | Time from active work start to merge or deploy | Time from commit (or backlog entry) to production deployment |
| Starts when | First commit or "in progress" status | First commit or ticket creation |
| Ends when | Merge to main or deploy event | Deployment to production |
| Best for | Diagnosing development and review process friction | Measuring end-to-end delivery performance for DORA benchmarking |
Use development cycle time to diagnose where in the development process time is being lost, and use lead time for changes when you need a standardized benchmark for overall delivery performance.