How can I use the Lead/Cycle Time report to track issue completion times?

The Lead/Cycle Time report helps you understand how long issues take to complete and identify bottlenecks in your development process. Whether your team uses estimation or not, this report provides valuable insights for predicting completion times and improving workflow efficiency.

Finding your Lead/Cycle Time report

Navigate to the Reports section in Zenhub and select "Lead / Cycle Time" from the available reporting options. The report loads automatically with data from your workspace repositories, showing completion times for all closed issues.

Use the date range selector to choose your analysis period. Available options include Past 14 days, 30 days, 3 months, 6 months, 12 months, 24 months, or a custom date range that aligns with your team's development cycles.

The report includes several filtering options:

• Start pipeline: Once an issue enters this pipeline it will be considered started
• Completed pipeline: Once an issue enters this pipeline, or any subsequent pipelines, it will be considered complete
• Repos: Select specific repositories to include in the analysis
• Show pull requests: Toggle to include or exclude pull requests from the completion time analysis
• Labels: Find specific labels or type "not:" for exclusions
• Days: Choose date scale display in days or weeks

Reading the completion time chart

The Lead/Cycle Time report displays your completion data with several key visual elements and summary metrics:

Summary metrics at the top: The report shows key statistics including the number of issues moved through your selected pipeline range, average completion time, maximum and minimum completion times, rolling average, and median completion time.

Individual issue points: Each dot on the chart represents a closed issue or pull request. The horizontal position shows when the issue was completed, while the vertical position shows how many days it took to complete. "Grouped issues" points indicate multiple items completed on the same date.

Blue average line: Shows the average number of days to complete work across the entire selected time period, providing a baseline for planning purposes.

Green rolling average line: Displays a rolling average of recent completion times, helping you identify trends and recent changes in your process efficiency.

Gray shaded area: Represents the standard deviation or normal range of variation in completion times. Work within this area represents predictable variation, while items outside indicate unusual completion times worth investigating.

Completed issues table: Below the chart, scroll down to see detailed information for each completed item including start date, completion date, total completion time, and estimates.

Hover over any point to see specific details including title and exact completion time.

Understanding lead time versus cycle time

The report helps you measure two important completion time concepts by configuring the start and completed pipeline settings:

Lead time measurement: Set the start pipeline to your first pipeline (like "New Issues") and completed pipeline to your final stage (like "Closed"). This measures the total time from when work is first requested until it's fully completed, including any waiting periods. Lead time represents the complete stakeholder experience from request to delivery.

Cycle time measurement: Set the start pipeline to when active work begins (like "In Progress") and keep the completed pipeline at your final stage. This measures only active work time, excluding waiting periods in backlogs or planning stages. Teams typically have more direct control over cycle time through process improvements.

Custom workflow analysis: Use any combination of start and completed pipelines to analyze specific parts of your workflow. For example, set start pipeline to "Code Review" and completed pipeline to "Testing" to understand just that portion of your process.

Large differences between lead time and cycle time indicate work spends significant time waiting before active development begins, suggesting capacity or prioritization challenges that need addressing.

Customizing your analysis with filters and settings

Configure the various report options to analyze different aspects of your workflow:

Pipeline configuration: Adjust the start pipeline and completed pipeline settings to focus on specific parts of your workflow. The start pipeline defines when timing begins, while the completed pipeline (and any subsequent pipelines) defines when work is considered finished.

Repository filtering: Use the Repos filter to analyze completion times for specific repositories when working across multiple codebases, helping you understand performance differences between projects.

Pull request inclusion: Toggle "Show pull requests" to include or exclude pull requests from your completion time analysis, depending on whether you want to focus purely on issues or include all development work.

Label-based analysis: Use the Labels filter to focus on specific types of work. Type label names to include them, or use "not:" followed by a label name to exclude specific work types from your analysis.

Time scale adjustment: Switch between Days and Weeks in the date scale to match your team's planning and review cycles. Weekly views can be helpful for longer-term trend analysis.

These filtering options help you create focused analyses that answer specific questions about your team's completion patterns.

Interpreting completion time patterns

Use the chart patterns to assess your team's workflow health and predictability. When most points cluster near the average line within the gray shaded area, this indicates predictable completion times that support reliable planning and stakeholder communication. Your team can confidently estimate future delivery times when completion patterns are consistent.

Issues scattered widely above and below the average, especially outside the gray area, suggest unpredictable completion times that make planning difficult and require investigation. This variability often stems from inconsistent workflows, varying issue complexity, or process inefficiencies that need addressing.

Pay attention to the green rolling average line for trend analysis. When this line trends upward, recent issues are taking longer to complete than your historical average. This pattern often indicates developing process issues that need attention. Downward trends show improving completion times, suggesting successful process optimizations.

Issues significantly above the gray area took unusually long to complete and warrant investigation to understand what caused the delay. Similarly, issues that completed unusually quickly (below the gray area) are worth examining to understand if there are practices you can replicate for other work.

Identifying common workflow issues

Learn to recognize chart patterns that indicate specific process problems. Gaps in chart points indicate periods when no issues were completed, possibly due to overcommitment, capacity constraints, or external dependencies that temporarily halted progress.

When you see many outliers above and below the gray area, this suggests an unpredictable process where completion times vary significantly. This pattern typically results from inconsistent workflows, unclear requirements, or unexpected complications that disrupt normal work flow.

Sharp upward trends in the rolling average line provide early warning about developing process issues before they severely impact delivery. This pattern often appears weeks before teams notice delivery problems, giving you time to investigate and address the underlying causes.

Charts with minimal outliers, stable rolling averages, and most points near the average line indicate healthy, predictable processes. These patterns support reliable planning and help teams make confident commitments to stakeholders.

Using completion data for process improvement

Transform Lead/Cycle Time insights into actionable workflow improvements. Use specific pipeline ranges to identify workflow stages with consistently long completion times, then focus improvement efforts on those areas that will have the biggest impact on overall delivery speed.

Work to reduce completion time variability by addressing the root causes of outlier completion times. When your workflow becomes more predictable, you can make more reliable commitments to stakeholders and plan future work with greater confidence.

Compare completion time patterns before and after process changes to measure the effectiveness of workflow improvements. This approach helps you validate which changes actually improve delivery speed and which might need further refinement.

Use average completion times combined with your team's throughput data to make realistic delivery timeline commitments to stakeholders. Historical completion data provides the foundation for evidence-based planning discussions.

Team retrospectives and continuous improvement

Leverage Lead/Cycle Time data during team retrospectives and planning sessions:

Retrospective discussions: Use outlier issues as discussion points to understand what caused unusually fast or slow completion times and how to replicate successes or avoid problems.

Process experimentation: Try workflow changes and measure their impact through completion time trends over subsequent periods to validate improvements.

Workload management: Analyze completion time patterns during different workload periods to understand your team's capacity limits and optimal work distribution.

Predictability goals: Focus improvement efforts on reducing completion time variability to enable better planning and more reliable stakeholder commitments.

Sharing completion time insights

Communicate workflow performance effectively using Lead/Cycle Time data:

Stakeholder reporting: Use average completion times and trend data to provide realistic timeline expectations for future work and explain delivery planning approaches.

Process transparency: Share completion time patterns to help stakeholders understand workflow constraints and the reasoning behind delivery timeline estimates.

Report sharing: Click the "Share" button to generate shareable links or export data to CSV format for detailed analysis, including repo, issue title, estimates, pipeline dates, and completion times.

Improvement communication: Use before-and-after completion time comparisons to demonstrate the impact of process improvements and justify workflow optimization investments.

FAQ

Q: What's the difference between lead time and cycle time?
A: Lead time measures total time from issue creation to completion (including waiting time), while cycle time measures only active work time from when work begins to completion. Lead time shows stakeholder experience; cycle time shows internal process efficiency.

Q: Why are some of my completion times much longer than others?
A: High variability usually indicates differences in issue complexity, unexpected blockers, or inconsistent workflows. Issues outside the gray shaded area deserve investigation to understand what made them unusual.

Q: How do I know if my completion times are good?
A: Focus on predictability and trends rather than absolute numbers. Stable averages with minimal outliers indicate healthy processes, regardless of whether completion takes 3 days or 30 days.

Q: Can I use this report if my team doesn't estimate issues?
A: Yes! Lead/Cycle Time reports work entirely based on issue movement through pipelines and don't require story point estimates. They're particularly valuable for teams using Kanban or other non-estimation approaches.

Q: What should I do about outlier issues that took much longer than normal?
A: Investigate outliers during retrospectives to understand what caused the delay. Common causes include unclear requirements, unexpected complexity, external dependencies, or workflow bottlenecks that need addressing.

Q: How often should I review completion time data?
A: Review completion time trends during monthly retrospectives or when you notice changes in delivery predictability. Use the data to guide process improvement discussions and measure the impact of workflow changes.