Cycle Time: Measuring Development Efficiency from Start to Finish

What Is Cycle Time?

Cycle time in software development measures the duration from when a developer starts working on a task (typically when it moves to 'in progress') to when that work is completed and deployed. This captures the active development lifecycle including coding, testing, review, and deployment.

Cycle time differs from lead time in its starting point. Lead time measures from when a request is made (e.g., a ticket is created or prioritised), including time spent waiting in the backlog. Cycle time begins when active work starts, making it a more precise measure of development efficiency rather than overall process efficiency.

Understanding this distinction is important because it determines where you focus improvement efforts. High lead time with low cycle time suggests your bottleneck is in prioritisation and queue management, not development efficiency. High cycle time indicates the development process itself has friction that needs addressing.

Measuring Cycle Time Effectively

Track cycle time using your project management tool's workflow timestamps. When a ticket moves from 'to do' to 'in progress,' that marks the start. When it moves to 'done' or 'deployed,' that marks the end. Most tools (Jira, Linear, Shortcut, etc.) capture these transitions automatically, making cycle time straightforward to calculate.

Report cycle time as a median with percentile ranges. The median gives you the typical experience, whilst the 85th or 90th percentile shows worst-case scenarios. A large gap between median and 90th percentile indicates high variability, which makes planning difficult and warrants investigation.

• Use project management tool workflow transitions for automatic cycle time tracking
• Report median and 90th percentile for a complete picture
• Break cycle time into sub-stages: coding, review, testing, deployment
• Track cycle time by work type: features, bugs, technical debt, spikes
• Use rolling averages (4-week) to smooth out natural variation

Cycle Time Benchmarks

High-performing teams typically achieve median cycle times of 1-3 days for standard work items. Elite teams may achieve sub-day cycle times for well-defined tasks. Teams with cycle times exceeding two weeks likely have significant process or technical bottlenecks worth investigating.

Cycle time varies significantly by work type. Bug fixes often have shorter cycle times than new features because they have clearer scope and established patterns. Technical debt items may have longer cycle times due to their exploratory nature. Track cycle time by work type for more meaningful benchmarks.

As with other metrics, your own historical trend is more useful than external benchmarks. If your team's median cycle time is 5 days and you reduce it to 3 days, that is a 40% improvement that translates directly into faster delivery for your users. Set incremental targets based on your current baseline.

Strategies to Reduce Cycle Time

Break work into smaller, well-defined tasks. Large, ambiguous tasks naturally have longer cycle times because they require more development time, more review time, and more testing. Effective task decomposition is a skill that engineering managers should actively develop in their teams through coaching and retrospective discussions.

Reduce wait states within the cycle. Time spent waiting for code review, waiting for CI/CD pipelines, waiting for environment availability, and waiting for approval all inflate cycle time without adding value. Map your development workflow and identify every point where work pauses. Each pause is an opportunity for improvement.

• Decompose work into tasks that can be completed in 1-2 days
• Identify and eliminate wait states in your development workflow
• Set code review turnaround SLAs (e.g., first review within 4 hours)
• Optimise CI/CD pipeline speed to reduce build and test wait times
• Limit work in progress to reduce context switching and improve focus

Using Cycle Time for Planning

Cycle time data enables probabilistic forecasting without the overhead of story point estimation. Using historical cycle time distributions, you can answer questions like 'What is the probability that this feature will be done by Friday?' with data-driven confidence intervals. This approach is often more accurate than traditional estimation.

Monte Carlo simulation, which uses historical cycle time data to model future delivery, is becoming increasingly popular as an alternative to velocity-based planning. Tools like ActionableAgile and Jira's built-in forecasting features support this approach. It requires only cycle time data, eliminating the need for story point estimation entirely.

When using cycle time for planning, ensure your work items are reasonably consistent in size. If your cycle time distribution has a very long tail, it indicates some items are much larger than others, which reduces forecasting accuracy. Consistent task sizing improves both cycle time predictability and planning reliability.

Key Takeaways

• Cycle time measures from work started to work completed, reflecting active development efficiency
• High-performing teams achieve median cycle times of 1-3 days for standard work items
• Smaller, well-defined tasks and reduced wait states are the keys to shorter cycle times
• Cycle time data enables probabilistic forecasting without story point estimation overhead
• Track cycle time by work type and use rolling averages for meaningful trend analysis