What Are Cycle Time?
The total elapsed time from when a developer starts working on a task to when it is delivered to production. Includes coding, review, testing, and deployment.
2-minute setup • No credit card required
What it means
Cycle time in software engineering measures how long it takes for a unit of work to move through the entire development pipeline. It typically starts when a developer moves a ticket to 'In Progress' (or makes their first commit) and ends when the code is deployed to production. Cycle time includes all stages: active development, code review, CI/CD, manual testing, and deployment. Unlike lead time for changes (a DORA metric that starts at first commit), cycle time often includes the time a developer spends understanding requirements and designing a solution before writing code. Cycle time is a Lean manufacturing concept adapted for software — in manufacturing, it's the time to produce one unit; in software, it's the time to deliver one feature, fix, or improvement. Shorter cycle times mean faster feedback loops, quicker value delivery, and more agile teams.
Why Cycle Time matter
Cycle time is the most direct measure of how long it takes your team to go from idea to working software. Product managers care about it because it determines how quickly features reach users. Engineering managers care because it reveals process inefficiencies. If your average cycle time is 10 days but coding only takes 2 days, you have 8 days of waste in reviews, approvals, and waiting. Tracking cycle time by stage (coding time, review time, deploy time) lets you pinpoint exactly where work gets stuck. Teams that reduce cycle time ship more features per quarter, respond to bugs faster, and iterate on product feedback more rapidly.
How to measure
Define start and end points consistently. Start: when a developer begins work (first commit or ticket moved to 'In Progress'). End: code deployed to production. Track via your project management tool (Jira, Linear, Shortcut) integrated with git data. Calculate the median cycle time per week or sprint — median is more useful than mean because a single blocked PR can skew the average. Segment by work type: feature cycle time, bug fix cycle time, and tech debt cycle time often have very different distributions. Aim to reduce P75 and P90 cycle times, not just the median.
Real-world example
A team tracks their cycle time for a sprint and finds the median is 6.5 days. Breaking it down: coding averages 1.5 days, waiting for review averages 2 days, review itself takes 0.5 days, CI runs take 20 minutes, and waiting for the weekly deploy window adds 2.5 days on average. The two biggest opportunities: eliminating the deploy window (switch to continuous deployment) and reducing review wait time (add a review SLA and require two small PRs instead of one large one). After these changes, median cycle time drops to 2.5 days.
Related terms
Common questions
What's the difference between cycle time and lead time?
Cycle time starts when work begins (developer picks up the task). Lead time starts when the work is requested (ticket created or commit made). Lead time includes queue time — how long the task sat in the backlog before someone started it. Cycle time is more useful for measuring engineering efficiency; lead time is more useful for measuring overall delivery speed from a customer's perspective.
What is a good cycle time for software development?
It depends on the type of work. For bug fixes and small improvements: 1-2 days is excellent. For standard features: 3-5 days is strong. For larger initiatives broken into PRs: each PR should still cycle in 2-3 days. If your median cycle time exceeds 2 weeks, there are likely significant process bottlenecks worth investigating.
How do you reduce cycle time?
Five proven approaches: (1) Break work into smaller units — smaller PRs cycle faster, (2) Set code review SLAs (e.g., review within 4 hours), (3) Automate testing and deployment to eliminate manual gates, (4) Limit work in progress (WIP) so developers finish tasks before starting new ones, (5) Use feature flags to ship incremental work without waiting for the full feature.
Does cycle time apply to bug fixes and features the same way?
Track them separately. Bug fixes should have shorter cycle times (often under 1 day for critical bugs). Features are larger and naturally take longer. Comparing them in the same metric hides useful information. Most teams report cycle time segmented by work type: features, bugs, tech debt, and infrastructure.
Track Cycle Time Automatically
Gitmore turns your git activity into automated reports with real metrics — delivered to Slack and email.
Get Started FreeNo credit card • No sales call • Reports in 2 minutes