Intro 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.
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 statistical variance, 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’s still within the grey area though, which means it’s still within a “normal” amount of time.
These Issues however, were closed significantly faster (top issue) and slower (bottom issue) than the normal range and should be discussed during the team’s retro.
By default, the CCR shows how long it takes Issues to move through the entire process (i.e. from New Issue → Closed). 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, until it exited the last pipeline.
For example, if you wanted to understand how long Issues remain in QA, you could set the range from Code Review → Testing.
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 Issue→Closed.
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 Progress→Closed.
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.
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 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.