What is Cycle Time?
Cycle Time is one of the most critical metrics in agile software development, representing the elapsed time from when work begins on a feature, user story, or task until it’s completed and delivered to the customer. Unlike Lead Time, which measures from the moment work is requested, Cycle Time focuses specifically on active development time.
Think of it as the heartbeat of your delivery process – it tells you how quickly your team can transform ideas into working software once they commit to the work.
Understanding the Measurement
The Basic Formula
Cycle Time = End Date - Start Date
However, the devil is in the details. Teams must clearly define:
- Start Point: When does work actually begin? (e.g., when moved to “In Progress”, “Development Started”)
- End Point: When is work truly complete? (e.g., “Done”, “Released to Production”, “Accepted by Customer”)
Common Measurement Approaches
Story-Level Cycle Time Measures individual user stories or features from start to completion. This provides granular insights into delivery patterns.
Epic-Level Cycle Time Tracks larger pieces of work, useful for understanding delivery of substantial features or initiatives.
Defect Cycle Time Specifically measures how quickly bugs are resolved, often tracked separately from feature development.
Workflow States Diagram
The diagram below illustrates a typical development workflow and shows exactly where cycle time measurement begins and ends:
This visual representation helps teams understand that cycle time specifically measures active development time, excluding time spent waiting in queues before work begins.
How Teams Can Improve Cycle Time
1. Identify and Eliminate Bottlenecks
Use cumulative flow diagrams to spot where work queues up. Common bottlenecks include:
- Code review processes taking too long
- Testing phases creating delays
- Deployment processes that are manual or unreliable
- Dependencies on external teams or systems
2. Reduce Work in Progress (WIP)
Implementing WIP limits forces teams to focus on completing work rather than starting new items. This reduces context switching and helps identify blockers more quickly.
3. Break Down Large Work Items
Smaller stories flow through the system faster and provide earlier feedback. Aim for stories that can be completed within a few days rather than weeks.
4. Automate Repetitive Tasks
Investment in automation pays dividends in cycle time reduction:
- Automated testing pipelines
- Continuous integration and deployment
- Automated code quality checks
- Environment provisioning
5. Improve Handoff Processes
Smooth transitions between team members or stages reduce delays:
- Clear definition of done for each stage
- Standardised handoff procedures
- Good documentation and communication practices
6. Address Technical Debt
Technical debt slows down development over time. Regular investment in code quality, refactoring, and infrastructure improvements maintains healthy cycle times.
Understanding Cycle Time Distribution
Rather than focusing solely on averages, teams should examine the full distribution of their cycle times:
Cycle Time Histogram Example
Cycle Time Distribution (Days)
0-2 days: ████████████████████ (40%)
3-5 days: ████████████████ (32%)
6-10 days: ██████████ (20%)
11-20 days: ████ (8%)
20+ days: ▓ (<1%)
Average: 4.2 days
85th Percentile: 8 days
95th Percentile: 15 days
The 85th percentile is often more meaningful than the average, as it represents predictable delivery for most work items whilst excluding outliers.
Risks and Anti-Patterns
The Gaming Problem
When cycle time becomes a primary target, teams may game the system:
Clock Stopping: Moving items back to earlier stages to reset timers Cherry Picking: Only taking on easy, quick tasks to improve metrics
Scope Creep in Reverse: Reducing quality or cutting corners to hit time targets Definition Manipulation: Changing start/end definitions to show improvement
Quality Degradation
Pressure to reduce cycle time can lead to:
- Skipping proper testing procedures
- Inadequate code reviews
- Technical debt accumulation
- Poor documentation
Inappropriate Comparisons
Comparing cycle times across different types of work or teams can be misleading:
- Bug fixes vs new features
- Simple CRUD operations vs complex algorithm development
- Teams with different skill levels or domain expertise
- Work requiring external dependencies vs self-contained tasks
Preventing Gamification
1. Use Multiple Metrics
Balance cycle time with:
- Quality metrics: Defect rates, customer satisfaction
- Throughput: Number of items completed
- Predictability: Variance in delivery estimates
- Value delivery: Business outcome metrics
2. Focus on Trends, Not Absolutes
Look for sustained improvement over time rather than hitting specific targets. Celebrate progress whilst investigating anomalies.
3. Understand Context
Always consider:
- Complexity of work being delivered
- External factors affecting the team
- Changes in team composition or skills
- Infrastructure or tooling changes
4. Involve the Team in Analysis
Teams should own their metrics and drive improvement initiatives. This reduces the likelihood of gaming and increases buy-in for genuine improvements.
Cycle Time in Different Contexts
Kanban Teams
Cycle time is a core metric, often displayed on cumulative flow diagrams and used for probabilistic forecasting.
Scrum Teams
While sprint-based, tracking cycle time within sprints helps identify process inefficiencies and supports continuous improvement.
Support Teams
Cycle time for incident resolution provides insights into operational effectiveness and customer impact.
Advanced Cycle Time Analysis
Cycle Time Breakdown
Understanding where time is spent within the cycle:
Average 8-day Cycle Time Breakdown:
Development: 3 days (37.5%)
Code Review: 1 day (12.5%)
Testing: 2 days (25%)
Deployment: 0.5 days (6.25%)
Waiting/Blocked: 1.5 days (18.75%)
This analysis reveals that nearly 19% of cycle time is wait time – a clear improvement opportunity.
Seasonal and Trend Analysis
Cycle times may vary based on:
- Team capacity (holidays, training periods)
- External factors (compliance deadlines, market events)
- Technical factors (infrastructure changes, major releases)
Tracking these patterns helps with planning and expectation setting.
Tools and Implementation
Popular Tools for Cycle Time Tracking
- Jira: Built-in cycle time reports and custom dashboards
- Azure DevOps: Analytics and custom queries
- Linear: Native cycle time tracking and insights
- GitHub: Third-party analytics tools and API integrations
Getting Started
- Define your workflow stages clearly
- Establish consistent start and end points
- Collect baseline data for 4-6 weeks
- Analyse patterns and identify improvement opportunities
- Implement changes incrementally
- Monitor impact and adjust
Conclusion
Cycle time is a powerful metric for understanding and improving delivery performance, but it must be used thoughtfully. When balanced with quality metrics and understood in proper context, it provides valuable insights into team effectiveness and process health.
The goal isn’t simply to reduce cycle time at any cost, but to create a sustainable, predictable delivery process that consistently provides value to customers. By focusing on genuine process improvements rather than metric manipulation, teams can achieve faster delivery whilst maintaining high standards.
Remember: the best cycle time metric is one that drives the right behaviours and helps your team deliver better outcomes for your customers.