Help Center
Note: Zenhub's full feature set is unlocked when you connect your GitHub Organization to Zenhub

Introduction to control charts

The control chart report (CCR) provides cycle time and lead time, or how long issues take from start to finish. Whether your team is using estimation or not, this chart can help predict how quickly upcoming issues will be closed, as well identify bottlenecks and efficiencies in each stage of your process.  



Overview of ZenHub's control chart report

The control chart report is based on closing issues and the movement of work through your pipelines. So regardless of your team’s methodology, workflow, or whether or not you estimate, the chart can help the team and stakeholders:

  • Calculate your cycle time and lead time 
  • Predict the average completion time of issues 
  • Provide stakeholder visibility into your process
  • Uncover blockers and bottlenecks in specific areas of your process
  • Identify abnormalities—both negative and positive—to help improve process 


Understanding the control chart

Points on the chart

Each point on the chart represents a closed Issue. Solid points represent a cluster of closed issues, or multiple issues that were closed on the same day. Hovering your curser over a point will provide more information about the issue, including the title and number of days it took to close. 


The x- and y-axis

The x-axis (along the bottom) is date, and shows the date that the issue was closed on. The y-axis (up and down) is number of days, or how many days it took for the issue to be closed.


For example, this issue was completed on February 24 (x-axis) and took four days (y-axis) to complete (based on the pipeline settings you've filtered the report by - more on this below):



Average and rolling average

The blue line shows the average number of days it takes to close an issue for the entire time period selected. The green line shows a rolling average of the number of days it takes to close the most recent issues, which helps identify trends or recent changes in your process. By understanding how long it takes to close issues or your velocity, you can better predict how quickly upcoming issues will be completed.


For example, this CCR shows that it takes 7 days on average to close an issue. However, the rolling average (green line) is trending upward, indicating that recently issues have been taking longer to close. 


This should prompt a conversation among the team about what could be causing this change in velocity.



Standard deviation

No matter how much you perfect your process, there’s always going to be some variation in how long it takes to complete issues. Some issues are closed slightly faster than average, and some are closed slightly slower than average—this is normal and should be expected. What’s important to watch for is the outliers, or issues that take a significantly longer or shorter time to close.  


The grey shaded area, or standard deviation, helps differentiate between this “normal” variation and the outliers. Issues within the grey shaded area are part the normal, predictable variation, even if they fall above or below average. Issues outside the grey area have taken an unusually short or long time to be closed, and should be examined further to understand why this occurred.


For example: This issue took 12 days to close, which is slightly longer than average. It is still within the grey area which means it is within a “normal” amount of time.



These issues however, were closed significantly faster (bottom issue) and slower (top issue) than the normal range and should be discussed during the team’s retro.



Pipeline Range

By default, the CCR shows how long it takes issues to move through the entire process (i.e. from New IssueClosed). However, the range of pipelines can be adjusted. 


Select different starting and ending pipelines to uncover bottlenecks or efficiencies throughout the process. The chart will show the total time it took for the issue to move through the selected range, from the moment it entered the first pipeline, to the moment it enters the last pipeline.


For example, if you wanted to understand how long issues remain in Code Review, and the next step in your process was Testing, you could set the range from Code Review →   Testing




Note: If an issue moves in and out of the selected range multiple times, the report will calculate the total time the Issue spent in the selected range.


For example, if an issue spends two days in the   In Progress pipeline, is moved back to New Issues for three days, then returns to In Progress for two days, the CCR will count total time spent in In Progress as four days.


Understanding lead time and cycle time

Lead time is the total time from when an issue is created--or a feature is requested--until it’s completed. This includes time before work starts, such as time spent sitting in the backlog or icebox. In other words, it’s the total time a customer or stakeholder has to wait to receive a feature after they requested it.


Cycle time is the time from when work begins on an issue or feature, until it’s completed. Unlike lead time, the cycle time only includes the time when the issue is actually being actively worked on. Generally, the team has more control over the cycle time, and can influence it by making changes to their work process.




Finding your lead and cycle time

By adjusting the starting and ending pipelines in the pipeline range, you can target specific areas of your process for further insight.


Lead time: the starting pipeline should capture the moment the issue was created, or the first pipeline on your board. The ending pipeline should capture the moment when work is ‘completed’, however your team defines this (“done”, “QA”, etc.) For most teams, the range will be  New IssueClosed.


Cycle time: the starting pipeline should capture when work actually begins on the issue. The ending pipeline should capture the moment when work is ‘completed’, however your team defines this (e.g. Done or QA) For most teams, the range will be  In ProgressClosed


What does the ideal chart look like?

When viewing the chart, watch for these indicators of a healthy process:

  • Limited Variance - the smaller the grey shaded area, the more stable your process is. These issues consistently take the same amount of time to close, with very few that are significantly slower or faster. Less variance means you can predict your throughput (how quickly issues are completed) with a higher degree of confidence.
  • Stable Average - the rolling average line should remain fairly flat; a sharp incline means that issues are starting to take longer to close and can be evidence of a bottleneck in process. However, as with all changes in chart, use this as an opportunity to start a conversation. For example, changes to the rolling average could indicate issues are taking longer to close, but could also indicate that issues are getting more complex.


Levelling up

The data in the control chart should be used to iterate and improve your team’s processes:

  • Isolate specific sections of your process by changing the pipeline range. This will give you a more in-depth understanding of what’s happening at each stage.
  • Understand the impact of process changes you make (for better or for worse!) by looking at the lead time over a set period of time.
  • Look for big gaps between cycle time and lead time—ask yourself why are issues sitting for so long before getting worked on?

Sample chart scenarios

Stagnant work on the Board

The gap in points indicates a long period of time when issues weren’t being closed. Ask what was happening on the team during this time. Did they take on too much work? Is there a large cluster of issues later when they were all closed? What changes could be made to more evenly distribute deliverable work?



Unpredictable cycle and lead time

The significant number of outliers (points above or below the grey shaded area) indicate that this is an ‘out of control’ process. This means there’s a large variance in how long it takes to close issues, making it difficult to predict and plan for future issues. Discuss why there is so much variability—are the issues varying in complexity? Are there unseen blockers?



Bottlenecks in your workflow

The spike in the rolling average can be an early warning about problems in the process. Even if the overall average time it takes to close an issue is still acceptable, a spike in the rolling average shouldn’t be ignored. Reflect on what happened around the time of the incline, and the time leading up to it.



The ideal scenario

This is a good chart; minimal outliers means that the process is highly predictable and can be used more accurately for planning. The majority of points are close to the average, and a steady rolling average indicates a stable process.



Share your control chart

When viewing your control chart, you share out the results in multiple ways. You have the option to copy the link to the report, or you can export the report to CSV to further analyse and share insights gathered. To get the sharable link, or to export the control chart, navigate to your control chart where there is a Share option located in the top right.  The fields included in the export are:

  • Repo
  • Issue title
  • Estimate
  • Date the issue entered your Start pipeline
  • Date the issue entered your Completed pipeline
  • Completion time (in days)



 to

Did you find it helpful? Yes No

Send feedback
Sorry we couldn't be helpful. Help us improve this article with your feedback.