Cycle Time

Cycle Time measures how long it takes to complete a work item from the moment active work begins until it’s delivered to the customer. Unlike lead time, which includes waiting periods, cycle time focuses specifically on the duration of active development work, making it a critical metric for understanding team productivity and process efficiency. Organizations use cycle time to identify bottlenecks, predict delivery dates, and optimize their development workflows.

When cycle time is consistently low, it indicates efficient processes, quick decision-making, and streamlined workflows that enable rapid value delivery. High cycle times often signal process inefficiencies, resource constraints, or complex work that requires additional attention and optimization. This metric directly informs capacity planning, sprint planning, and resource allocation decisions.

Cycle time works hand-in-hand with related metrics like lead time, flow efficiency, and sprint velocity to provide a comprehensive view of development performance. While cycle time focuses on active work duration, lead time captures the complete customer experience, and flow efficiency measures the percentage of time spent on value-adding activities versus waiting.

“The key is not to prioritize what’s on your schedule, but to schedule your priorities. Cycle time helps us understand if we’re actually delivering on those priorities efficiently.”

— Stephen Covey, Author and Business Consultant

Calculating cycle time requires identifying when active work begins and ends for each work item. The measurement focuses on actual working time, excluding any waiting or queue periods.

Formula:
Cycle Time = End Date - Start Date

Start Date represents when active work begins on an item. In software development, this typically occurs when a developer picks up a task and begins coding. For manufacturing, it’s when production starts on a unit.

End Date marks when the work item is completed and ready for delivery. This could be when code is deployed to production, a feature passes final testing, or a product rolls off the assembly line.

The result is expressed in your chosen time unit—hours, days, or weeks—depending on your process and reporting needs.

Worked Example

A software team tracks these timestamps for a user story:

• Start Date: Developer begins coding on Monday, 9:00 AM
• End Date: Feature deployed to production on Wednesday, 2:00 PM

Calculation: Wednesday 2:00 PM - Monday 9:00 AM = 2 days, 5 hours = 53 hours total cycle time

For reporting purposes, this team might round to 2.2 days or keep the precise 53-hour measurement for detailed analysis.

Variants

Individual vs. Average Cycle Time: Track single items for specific insights or calculate averages across multiple items for trend analysis. Rolling averages over 30-90 days provide stable metrics for process improvement.

Phase-Specific Cycle Time: Measure cycle time for individual workflow stages (development, testing, deployment) to identify bottlenecks within your overall process.

Work Item Type: Calculate separate cycle times for different item types—bugs, features, or technical debt—since complexity and handling processes often vary significantly.

Common Mistakes

Including Wait Time: Don’t count periods when work items sit in queues or await approvals. Cycle time measures active work duration, not total elapsed time.

Inconsistent Start/End Definitions: Teams often change their definition of “work begins” or “work completes” without updating historical data, making trend analysis meaningless.

Ignoring Work Item Complexity: Averaging cycle times across vastly different work items (simple bug fixes with major features) creates misleading metrics that don’t reflect true process performance.

While wanting benchmarks for cycle time is natural, context matters significantly more than hitting specific targets. Use these benchmarks as a guide to inform your thinking, not as strict rules to follow.

Average Cycle Time Benchmarks

Understanding Context Over Numbers

These benchmarks help establish a general sense of what’s normal—you’ll know when something feels off. However, cycle time exists in tension with other critical metrics. As you optimize for faster delivery, you might see trade-offs in code quality, technical debt, or team burnout. Consider related metrics holistically rather than optimizing cycle time in isolation.

How Related Metrics Interact

For example, if you’re aggressively reducing cycle time from 4 weeks to 1 week, you might see your defect rate increase as teams rush to meet shorter deadlines. Alternatively, investing in better tooling and processes might simultaneously reduce both cycle time and defect rates, but could temporarily slow feature velocity as teams adapt. The key is monitoring how changes in cycle time affect sprint velocity, flow efficiency, and issue resolution time to ensure you’re improving overall delivery effectiveness, not just speed.

When cycle time stretches beyond expectations, it signals inefficiencies in your development process that directly impact customer value delivery and team productivity.

Work Items Are Too Large
Look for stories consistently taking weeks instead of days to complete. Large work items create unpredictable cycle times and increase risk. Teams often underestimate complexity, leading to scope creep mid-development. Breaking work into smaller, deliverable pieces is essential for cycle time optimization.

Too Much Work in Progress
Monitor your team’s active work items versus capacity. When developers juggle multiple tasks simultaneously, context switching kills productivity. You’ll see work items sitting “in progress” for extended periods with minimal actual advancement. Implementing WIP limits forces focus and reduces cycle time.

Frequent Rework and Quality Issues
Track how often work bounces between development and testing phases. High defect rates force developers to revisit completed items, inflating cycle time measurements. Poor code review processes or insufficient testing strategies create this rework cycle. Quality gates earlier in the process prevent downstream delays.

External Dependencies and Blocking
Examine how often work items wait for external teams, approvals, or resources. Dependencies outside your team’s control can dominate cycle time, even when actual development work is efficient. You’ll notice work items stalled in specific workflow stages repeatedly.

Inefficient Development Practices
Review your deployment frequency and code integration patterns. Teams practicing infrequent deployments often batch work, artificially extending cycle times. Manual testing processes, complex deployment procedures, or inadequate automation create bottlenecks that compound over time.

These issues cascade into reduced Sprint Velocity and poor Flow Efficiency, ultimately impacting customer satisfaction and team morale.

Break Down Large Work Items
Split oversized tasks into smaller, manageable pieces that can be completed within 1-3 days. Use story point analysis to identify consistently large items, then apply techniques like vertical slicing to create independently deliverable increments. Track the cycle time distribution before and after decomposition to validate that smaller items flow through your system faster.

Eliminate Context Switching
Reduce the number of concurrent work items per team member by implementing WIP (Work in Progress) limits. Analyze your team’s multitasking patterns using Jira data to identify when developers juggle multiple items simultaneously. Set WIP limits 20-30% below current levels and measure the impact on individual cycle times.

Streamline Code Review Process
Establish SLAs for code reviews (e.g., 4-hour response time) and track review queue times separately from active development time. Use cohort analysis to compare cycle times for items reviewed by different team members, identifying bottlenecks in your review process. Consider pair programming for complex features to reduce review overhead entirely.

Reduce External Dependencies
Map dependencies causing delays and work to minimize or eliminate them. Track cycle time by dependency type to identify which external factors create the most significant delays. For unavoidable dependencies, establish clear handoff protocols and SLAs with other teams to prevent work from stalling.

Optimize Your Development Workflow
Analyze cycle time trends across different types of work items (features, bugs, technical debt) to identify process inefficiencies. Use Flow Efficiency alongside cycle time to understand whether delays stem from waiting time or active work time, then target improvements accordingly.

Stop calculating Cycle Time in spreadsheets and struggling with manual data analysis. Connect your data source to Count and get instant cycle time calculations, intelligent segmentation, and automated diagnosis of bottlenecks in seconds.