I am running a kanban project, I am collecting cycle time data via control chart, what is the best way to use it?

  • What are your warning and/or control limits? Did you plot your central line (mean)?
    – Thomas Owens
    Dec 21, 2017 at 20:16

4 Answers 4


Control Charts Primarily Visualize Process Variability

While they show you some nice things like lead time and cycle time, the most beneficial metric that can come out of using a control chart is variability, and from that, the predictability of your process to produce value for your customers.

Teams can better understand their variability by inspecting 'outliers,' these are items that are either extremely high on the chart or extremely low. What happened to these items and why? What can we do to normalize them? Sometimes you can catch user stories created and instantaneously closed, what happened there? Did the development team just instantly implement something? No, perhaps it was something that was entered improperly or previously completed. What about some of the items that took extremely long to complete?

There are stories behind each one of those data points, and good teams use this kind of information to improve their process going forward. The idea isn't to get all of your items completed within a day or an hour, it's to get all of your items flowing through your board in a predictable and sustainable manner.

With more predictability, you can actually go back to your customers and tell them, accurately, when a feature may be ready for production +/- days or hours, etc. All depends on the project, but that is how you should be thinking about using a control chart.


The cycle time gives you feedback on the efficiency of your work process.

Try and tune the process, using this feedback to guide you.

For example, you could try:

  • Tweaking the work in progress limits
  • Spending more time on peer review and code pairing
  • Changing the amount of time spent refining the backlog

Typically you first come up with a hypothesis:

We keep bottlenecking on testing, so let's get more team members involved in testing and see if that improves throughput

Try it for a defined amount of time (say 3 weeks) and check the impact on the control chart. If the hypothesis is proven correct and cycle time reduces, proceed, else revert back.

  • Ah, so right now my average issue completion rate in JIRA is 1 day, is the end goal to get that line lower?
    – bobo2000
    Dec 17, 2017 at 13:20
  • 1
    Yes it is, although make sure that quality doesn't suffer as a result! Dec 17, 2017 at 17:13
  • Thanks, so what is much more important to measure productivity, cycle time against estimated time or the overall control chart?
    – bobo2000
    Dec 17, 2017 at 17:44
  • I'm not sure I see what value you get from cycle time against estimated time. Development estimates are notoriously inaccurate, there is always inherent uncertainty. Dec 17, 2017 at 22:43
  • then what's the point in measuring issue completion time?
    – bobo2000
    Dec 18, 2017 at 12:47

The 4 Cycle-time related charts that you should ideally be using in conjunction are the Cycle Time trend, Cycle Time (or Lead Time) Distribution chart, the Cycle Time Control chart and lastly the Flow Efficiency chart (the ratio of work time to total cycle time). Together, these give you a good measure of your team's performance and feedback on how and where you need to focus your improvement efforts.

Given below is a screenshot from our product SwiftKanban - which gives you all of these charts - there are other tools that do it too - and you can also compute these in a spreadsheet if you have the data. This is for one of the projects being managed in my company -

enter image description here

You might already know about all of them, so I won't go into details of each - but if you have any questions, I'd be happy to answer them!

As for the control chart - here is a close up of the chart above - pls forgive my horrible annotation of it!

enter image description here

Here's what the control chart helps you do - it helps you look at the cycle time performance of your team that you are currently observing. It shows you the average cycle time as well as the spread of the observed cycle time data points around the average. It also highlights the "outliers" in your data set. (The average cycle time trend chart in the previous picture fails to do that - but is useful to study overall cycle time trend.) Based on this chart's analysis, you can make predictions or commitments about the normally expected (or expectable) performance of your team.

In the chart above, section A tells you what are the Mean or Average Cycle time for the period under study (the date range of the chart), the Upper Control Limit (UCL) and the Lower Control Limit LCL). The UCL and LCL are calculated as the +/- 3-sigma (standard deviation) range on the two sides of the mean. Anything outside of this range is considered an outlier (items marked with B above) - something of an anomaly in your data set.

What the control chart tells you is what is your +/- 3-sigma spread (the range marked C in the chart above). The purpose of Kanban systems is to help you improve your predictability of delivery. The higher the spread, the higher the variation in your team's cycle time performance - and so the lower its predictability.

What you ideally want to try and do is to reduce that spread. As you study the individual data points, you and the team can figure out what went right for the items in the -3 sigma range (items between the Mean and the 0 lines), and what may have gone wrong in the +3 sigma range (between Mean and UCL lines), and especially those that are the outliers (above the UCL line).

As you start to fix those issues, you should start to see a narrowing of the spread (C) and hopefully a reduction in the number of outliers (B) as also a reduction in the Mean value as overall system performance improves. Using the control chart, you should be able to see a chart like the one shown in this blog post - Implementing Kanban in IT Operations - which looks like this -

enter image description here

So the control chart can help you track your performance improvement as you introduce process changes or other improvement initiatives, as also simply internalizing the principles of Kanban that gradually help you reduce WIP, improve Flow and Throughput - and ideally, both the cycle time and the cycle time variations.

Hope this helps!


The main purpose of the control chart is to see how much variability you have in your work. Pay close attention to spikes/dips and put some time into investigating what caused those items to take longer/shorter. The control chart can help you become predictable (you will know that any piece of work will on average take X days) One item you should avoid is getting concerned when something dips/spikes but remains inside your lower limit. You don't want to have an average of 1 week and start asking questions about what happened on day 8.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.