BY| February 20, 2017
Cycle time (or System Lead Time as some call it) is one of the most common metrics used to measure the effectiveness of a Kanban system. Cycle time is the time taken by a Kanban card to move from start to end on the board (or some part thereof). As you start using a Kanban system and implementing its principles, ideally the cycle time of the system should reduce. In David Anderson’s initial blogs “http://www.djaa.com/why-kanban-why-focus-lead-time-reduction” he has clearly emphasized the importance of reducing the lead or cycle time of a Kanban system. Besides the obvious advantage of “faster-time-to-market” or faster delivery of value to customer, lead time reduction usually mean reduction of wait times in the overall workflow as the Kanban system helps to highlight and reduce different types of waste, including time between handoffs, blocked time due to waiting on external (or internal) dependencies, etc.
One way to evaluate the cycle time performance of a Kanban system is to look at the well-known cycle-time distribution chart like the one shown below, generated in SwiftKanban. For this chart, we take all the cards that go through the Kanban board during a user-selected time period. On the X-axis are cycle time values that different cards took to traverse the board, on the Y-axis, is the number of cards, that get completed for each value of cycle time on the X-axis.
As you might notice, the “tail” of the distribution curve is quite long. The “outliers” are indicated in red. This pattern of long tails is fairly common in many Kanban systems as there is always a small set of cards that are outliers – that take a much larger amount of time than most other cards on the board – causing an increase in the average cycle time of a Kanban system. In the above scenario, the focus area for improvement for any Kanban team would be to make the tail of the curve shorter, because of the shorter the tail, the more predictable the system.
Looking Back, Looking Forward
The issue with the cycle time analysis is that it is a retrospective analysis, as the cards have already exited the board. Any delay in those cards has already occurred and while it is great to know why it happened, it is too late to do anything for those specific cards. Wouldn’t it be great if you could identify potential outliers from the from cards that still on the board? That way, you could intervene to help such move along and keep cycle time under control!
Well, to facilitate this, we have done just that in our last update! We have introduced a cycle time visualization which enables the team to focus on “live” cards with high cycle time and prioritize them first.
Cycle time thresholds and setting
If you see the chart above closely, you will see that on average, most of the cards get completed between weeks 0-15. Once they cross the week 15 mark, they go into the unpredictable outlier space. So if you consider the above, you would want to highlight right on the board, cards which have exceeded a cycle time of 15 weeks. But wait a minute, if you just did that, you would simply be highlighting cards where it is already too late! So, you might require another threshold, say around the week 10, to try and save cards between 10 and 15 weeks from entering the danger zone (of more than 15 weeks) Based on this, we have implemented a feature to highlight cycle time in SwiftKanban with 2 thresholds and a scale that can be set by the board manager.
There are several methods through which you can set the values of threshold 1, threshold 2 and scale for your board’s columns. Let me explain one of the methods which can be done using the SwiftKanban tool. In SwiftKanban there is an Analytic component of Cycle time-Control where you can select a specific column, for a specific date range. This metric will plot the cycle time values for all the cards that passed through that column. Shown below is a sample screen of the metric with the chart plotted for the same sample board.
As you can see above, the charts plot LCL, UCL and Mean values for the column automatically based on the data. We can have the mean as the first threshold 1 and scale will be the UCL value of the chart. As the UCL is 15.73, for our purposes, the scale of the chart can be around week 15. As the chart highlights, the mean cycle time is 4.29 weeks, so you can consider the week as the first threshold value, i.e. threshold 1. For threshold 2, the product doesn’t plot the third quadrant, but it is between the mean and UCL. Also, based on the above distribution chart and cycle time chart, we can conclude that it is around the week 9 and hence the threshold 2 value will be week 9.
Once you decide on the values, setting up these values on the board is a very quick and easy. In each board, in the Board Editor, we have provided an option for each column on the board to set 2 cycle time thresholds and a maximum “scale” value through which you want to measure the cycle time for all the cards in that column. This setting has been added right below the standard column settings, as you can see below in the sample screen.
If you hover over the icon on the right, you will see how exactly the cycle time performance of each card will be shown on the card.
If we consider the earlier example, for the first 15 weeks, the cycle time indicator line will be shown in green, between 15 and 18 weeks, it will be amber and beyond 18-20 weeks it will be red.
The above setting can be for any columns of the board depending on your requirement.
Viewing the Cycle time on the Kanban Board
Once the above settings have been saved and activated, to view the actual cycle time performance of cards on the board, click on the new icon provided on the floating left menu bar. The columns where the cycle time thresholds have been set will start highlighting the cycle time for all the cards right on the board itself. Shown below is a sample screenshot of such a Kanban board.
You will see on each card, a color line showing the current cycle time performance. The line color will depend on the threshold limits set, the current cycle time of each card. The 2 dots on the line indicate the Threshold 1 and Threshold 2 for the column. You can hover on each dot and find out the values of these thresholds. The example below shows a card that has exceeded Threshold 1 but is still within Threshold 2.
To hide the line, simply click on the same Cycle Time icon again. This setting will persist across sessions.
Voila! You are now empowered to proactively manage your cards’ cycle time performance.
Stop Starting, Start Finishing!
As the Kanban board is where the Kanban team converges daily and makes Pull-decisions, we have provided the visualization right where it matters the most on. We hope you will like it!
If cycle time performance is important for your team, please use the cycle time settings on your board to not only manage the current outliers but also to take care of cards which might potentially be the next set of outliers. This should help you reduce cycle time. Reducing the cycle time tail will get you greater predictability in your system.
There are several ways in which the new cycle time view can help users across different domains. Here are some examples:
- If you have multiple teams working on the same board, the expected delivery time (cycle time) can be set team wise.
- If you are using a Kanban board for ticket management, then you can map the SLA related to ticket resolution based on the appropriate column thresholds to better ensure SLA adherence.
- For IT operations, the downtime of the system can be mapped to the work time columns on the boards. So in case there is a system downtime crossing the threshold 1, the Kanban team will be immediately notified on the board. Based on the remaining work and time left between threshold 1 and 2, they can take the decision to go ahead or stop the activity.
These are just a few examples. There are many use cases across different kinds of teams. As I mentioned earlier in this article, the cycle time is one of the most important metrics to measure the effectiveness of a Kanban system. We hope this feature will help your team improve it’s cycle time!
Swiftkanban Product Owner