Cycle time is one of the most actionable metrics in software engineering. It tells you how long work takes from the moment someone starts it to the moment it ships. When cycle time is long, everything is affected: release frequency, feedback loops, and the team's ability to respond to changing requirements.
Most guides treat cycle time as a generic DevOps metric. This one covers the fundamentals, then goes deeper into what cycle time looks like for FinTech and regulated engineering teams, where the measurement and improvement levers are different.
What Is Cycle Time in Software Development?
Cycle time in software development is the time between when active work begins on a task and when that task reaches production. It starts when a developer picks up a ticket or creates a branch, and it ends when the code is deployed and available to users.
The formula is simple:
Cycle time = Delivery date - Work start date
What it does not include: the time a ticket sat in a backlog waiting to be picked up. That pre-work period is part of lead time. Cycle time measures only the engineering-controlled portion of delivery.
Cycle Time vs Lead Time: Why the Distinction Matters
Cycle time and lead time are often used interchangeably. Confusing them leads to the wrong diagnosis.
Lead time (general): Starts when a ticket is created or a request is made. Ends at production deployment. Measures the full time from request to delivery, including backlog wait.
Cycle time: Starts when a developer picks up the ticket or creates a branch. Ends at production deployment. Measures the engineering-controlled delivery window.
Lead time for changes (DORA): Starts at code commit. Ends at production deployment. Measures pipeline efficiency specifically.
If your cycle time is acceptable but lead time is long, the problem is upstream: requirements are sitting idle before engineering picks them up. If your DORA lead time for changes is long but cycle time is fine, the problem is in the deployment pipeline. Each metric points to a different bottleneck.
How to Measure Cycle Time
Cycle time can be measured at the ticket level, the pull request level, or the deployment level, depending on what your tooling supports.
Ticket-level measurement uses your project management tool. Start time is when the ticket moves to In Progress. End time is when it moves to Done or Deployed.
PR-level measurement uses your version control system. Start time is the first commit on a branch. End time is when the PR merges to the main branch.
Deployment-level measurement extends PR-level to include the full CI/CD run. This is the most accurate measure of true cycle time end-to-end.
The most useful measure for engineering leaders is deployment-level cycle time, tracked at the 50th percentile (median) and 85th percentile. The median tells you typical performance. The 85th percentile tells you how bad the outliers get.
Cycle Time Benchmarks
Industry data from LinearB and the DORA State of DevOps research provides reference points across performance tiers:
Elite: Under 1 day
High: 1 to 7 days
Medium: 1 to 4 weeks
Low: Over 1 month
LinearB benchmark data across thousands of engineering teams shows a median cycle time of about 3 to 5 days for teams that actively track the metric. Teams that do not track it tend to run longer, often by a factor of two or more.
For the DORA "lead time for changes" sub-metric, Elite teams achieve under one hour from commit to production. This is a narrower measurement than full cycle time, but it sets the context for what automated pipelines can achieve.
The Accelerate research by Forsgren, Humble, and Kim found that high-performing software delivery organisations had lead times measured in hours or days, compared to weeks or months for low performers. Faster delivery correlated directly with higher profitability, market share, and customer satisfaction.
For more on DORA benchmarks and how cycle time fits the broader delivery picture, see our complete DORA metrics guide.
Cycle Time for FinTech and Regulated Engineering Teams
Generic cycle time guidance assumes you control your own deployment pipeline end-to-end. FinTech engineering teams rarely do.
Regulated environments introduce mandatory gates that add time to every release: Change Advisory Board (CAB) approvals, security reviews, penetration testing windows, and compliance sign-offs. These are not optional and they are not inefficiencies to eliminate. They are requirements.
The result is that raw cycle time figures for FinTech teams are often longer than published benchmarks, which can look like underperformance when the engineering team is operating well.
The correct approach for regulated teams is to separate cycle time into two components:
Engineering-controlled cycle time: The time developers spend writing, reviewing, and deploying code. This is where engineering improvements happen.
Compliance-gated wait time: Time a release spends in mandatory review queues outside engineering control, including CAB approval, security sign-off, and change freeze periods.
Tracking both separately gives you an honest picture. If total cycle time is 12 days and engineering-controlled cycle time is 3 days, the bottleneck is in the compliance queue, not the engineering team. That finding points to a process design conversation, not a developer performance conversation.
Banking teams operating under PSD2, SOC 2, or similar compliance frameworks often find that improving cycle time requires working with risk and compliance functions on parallelism: running security reviews concurrently with development rather than sequentially after code freeze.
For a full picture of engineering delivery practices in financial services, see our engineering operations guide.
How to Reduce Cycle Time Without Cutting Corners
For the engineering-controlled portion of cycle time, the levers are well understood:
Reduce batch size. Smaller pull requests move through review faster. A PR with 50 lines of changed code ships in hours. A PR with 500 lines ships in days and carries more deployment risk when it does.
Limit work in progress. Context switching lengthens cycle time. When developers work on three things simultaneously, all three take longer. WIP limits force flow.
Speed up code review. Review delays are the most common cause of long cycle times in mature engineering teams. Set a review SLA: pull requests should receive a first review within four hours. Track it.
Automate test gates. Manual QA steps that block deployment add days to every cycle. Every manual gate that can be replaced by automated testing removes that time permanently.
Parallelise where possible. Many teams run code review, security scanning, and integration testing sequentially. Running them in parallel cuts the same steps to a fraction of the time.
For FinTech teams, the same principles apply to engineering-controlled time. The additional lever is process design: how much of the compliance gate can run in parallel with development rather than after it.
How Scrums.com Tracks Cycle Time
Scrums.com is an engineering intelligence platform that surfaces cycle time, DORA metrics, and sprint health data across your engineering teams in a single dashboard. It connects to Jira, GitHub, and your CI/CD pipeline automatically, tracking cycle time at the ticket, PR, and deployment level. Teams in regulated environments can segment cycle time by phase to separate engineering-controlled time from compliance-gated wait time. See how it works.
Frequently Asked Questions
What is cycle time in software development?
Cycle time in software development is the time between when active work begins on a task and when it reaches production. It starts when a developer picks up a ticket or creates a branch and ends when the code is deployed. It does not include the time a ticket sits in the backlog before anyone starts it.
What is a good cycle time for a software engineering team?
Based on benchmark data from LinearB and the DORA research program, Elite teams achieve a cycle time under one day for individual changes. High-performing teams average 1 to 7 days. Most teams actively tracking the metric fall in the 3 to 5 day median range. Teams that do not track cycle time tend to have longer cycles, often measured in weeks rather than days.
What is the difference between cycle time and lead time?
Cycle time starts when work begins, specifically when a developer picks up a ticket. Lead time starts when a request is made, meaning when a ticket is created. Cycle time measures the engineering-controlled portion of delivery. Lead time measures the full time from request to delivery, including any backlog wait before engineering starts.
How do you reduce cycle time in software development?
The most effective tactics are: reducing pull request batch size, setting WIP limits, establishing code review SLAs (first review within four hours), automating test gates, and parallelising steps that currently run sequentially. For regulated teams, running compliance reviews in parallel with development rather than sequentially after it is the highest-impact lever available.
How does cycle time relate to DORA metrics?
Cycle time and the DORA metric "lead time for changes" are related but different. Lead time for changes starts at code commit and ends at production deployment. Cycle time starts earlier, from when a developer begins work, and gives a broader view of the full engineering delivery window. Both are useful, but cycle time captures more of the team's actual workflow.
