November 10, 2010

Getting Started with Kanban - Answers for Some Mechanics

Let's assume you've read David Anderson's excellent Kanban book. You've started using Kanban on a project. Everyone notices how much more transparency there is in the process now. Some welcome that visibility. Others are not so happy about aspects of that visibility.

If you are reading this blog, you are probably not after Mechanical Agile. You are smarter than that. You want to add real value to your organization. You know that Kanban can help your team focus on flow and continuous improvement if you can figure out, in practical terms, how to use these metrics.

Let's say you've started well, with an understanding of what is important to your business and you have an improvement goal. Maybe you want to start measuring cycle time, want to have a Cumulative Flow Diagram and want to create a frequency distribution diagram or process control chart. You are getting started but the book leaves many details about how to do that as an exercise for the reader. Rightly so. You certainly wouldn't want a specific tool to be prescribed just as Kanban doesn't prescribe which improvement model to use, of which there are many: Deming, Lean, Theory of Constraints, etc.

Thinking back on some questions I had when I started using Kanban I realize many of them had nothing to do with improvement models. They were more basic. In hopes that this may help you, I provide some of the answers I've come across or come up with. I give credit for the good answers to conversations I've had with Dennis Stevens and others. The stupid answers are all mine.

After counting days blocked, do you exclude those blocked days from each item's duration?
No. What you are after with cycle time is how long on average it takes to pull something through the system. Blockage happens. It's part of the cycle. You want to know how long it will take to get an average story through the system with average blockage. You use the days blocked as another, separate metric available for analysis and improvement.

When something has been on hold for a long while and gets dumped, do you include that item in your average cycle time calculations?
Sometimes things get blocked so long that that you give up. Or should give up. Toss that effort in the trash. Forget about it. Write it off. Maybe it will come back again someday, but when it does, you might as well start over. Just dump it. Don't directly include that item in your average cycle time. I say don't "directly" include it because it has had an impact on the metrics. It took up time and effort and caused other items to be delivered later than they could have been. So that item had an impact on your cycle time even though you exclude that item from the metrics. If you were to consider the item's end date the date it got blocked and include that item in the average cycle time, this would make your cycle time look shorter than it really is. Conversely, you could skew your cycle time towards having too much buffer if you held onto the item too long and consider its end date the date you dumped it. So, no, don't include the item in your average cycle time.

Do you include weekends in your lead time calculation?
Eh, do whatever you want. If your average lead time is greater than a week and if your business thinks in terms of calendar time, include them. If your average lead time is around a week or less and if your business thinks in terms of business days, then exclude weekends. Excel has a networkingdays function you can use.


For quick items that start and end on the same day, should I count it as a day or as a half a day?
If your average cycle time is much greater than a day and this happens rarely, count it as a day. It's not worth the effort to do differently. If it's rare that any item takes 2 days to finish, then consider measuring at a granularity finer than a day -- measure in hours. If your average cycle time is a couple days and this happens often enough, count it as a half-day -- measure in half-day increments.

How do I graph a frequency distribution using excel?
Use a bar chart. I put the cycle time durations I care about in a column: .5, 1, 2, 3, 4, 5, 6, 7, 8, etc. These are the "bins" that feed the FREQUENCY formula. Name the binsRange and name the durationsRange. Next to those bins, is an array formula: select the range, type in the formula =FREQUENCY(durationsRange,binsRange), and press ctrl-shift-enter. Then I graph the bins and frequency as a bar chart as shown in the image at the top of this blog post.

How do I graph a Statistical Process Control Chart using excel?
I'm assuming you already have columns for completed date and duration. There must be a better way, but the quick and dirty approach is to add a column for the mean and upper and lower control limits and upper/lower spec limits. These columns will have the same value (the mean, or the mean plus/minus three standard deviations, or the spec limit) in all rows. Select those 5 or 7 columns: date, duration, mean, upper/lower control and upper/lower spec limit. Insert a X Y (scatter) chart. Select the mean series, right click, and Change Series Chart Type to a Line chart. Do the same for the other control lines. VoilĂ !

I hope this has been useful. If so, let me know.

What questions of this sort have you resolved or do you still have?


  1. Regarding the Upper and Lower control limits, if you have the full population of data for all your stories (rather than just a sample), then the UCL and LCL are simply 3 standard deviations about the mean. Use the population form of stddev in excel, not the sample form of that function.

    There is another formula you must use for UCL and LCL when working with samples rather than the full population. I won't go into it here, but I put a poor explanation of it in a comment to

  2. At LSSC12 a very strong argument was made against using standard deviations for the types of distributions we normally (no pun intended) get out of measuring software development activities. Those distributions aren't always normal distributions. Most people can't discern what type of distribution they have. So instead, just use percentiles -- report that x% of the items took n days.