A Beginners Guide to Kanban Tools

Kanban boards are widely used in the modern IT landscape. Teams use them to map their workflow and their current tasks in progress. This creates transparency and facilitates prioritization. Unfortunately, many teams lack the knowledge and possibilities to assess the performance of their workflow. How quickly are things being processed? Are we focused, or are we doing too many things at once? These and similar questions can be answered by using tools to analyze the different flow metrics in a Kanban environment.

Kanban Metrics for Software Teams

Kanban as a tool of lean management has its origins in the Toyota Production System of the 1970s. Over time, it became the de facto standard in the automotive industry. In the course of the 2000s it found its way into software development and since then it is hard to imagine IT without it.

Kanban implementations in physical manufacturing and IT differ significantly. Not every process, nor every metric, from physical manufacturing plays a role in IT. The relevant metrics for software teams, especially when working with Scrum, are defined and presented in the Kanban Guide for Scrum Teams. In the following, we will take a look at which tools we can use to evaluate these metrics in order to analyze the performance of a team.

Tools to Analyze Your Kanban Metrics

This article is not about software tools that can help us organize a Kanban board. It is not about Atlassian Jira, Microsoft Azure DevOps or Trello. It is also not about platforms or plugins that provide analysis capabilities, like ActionableAgile or Nave. It’s about the tools themselves. Which tools can we use to analyze the performance of our team?

As mentioned before, not all available Kanban metrics are relevant for software development or IT teams. Therefore, in the following, we will limit ourselves to the analysis of the useful metrics. These are lead time, throughput, work item age and the amount of work items in progress (WIP). Furthermore, we will look at the control flow diagram as an additional tool.

Cycle Time Scatter Plot

Cycle time scatter plots show the cycle time distribution of different tasks over time. You could also call this a cycle time run chart. It displays the cycle times of the tasks which have been delivered on the respective days. The x-axis represents the progression over time, while the y-axis shows the actual cycle time of the tasks. The trend line represents the average cycle time in a window of twenty days.

This cycle time scatter plot shows the system cycle time of the development process. This contains all processing steps from the start of work on the task until it is delivered/closed. Namely, the software development itself and the code review. It is clearly visible that this Scrum team is able to complete 95% of the tasks within the 14-day time frame of their two-week sprints.

Compared to the previous chart, this one represents the customer cycle time or lead time. It includes all steps from the point a requirement is raised to its delivery. This time can also be referred to as time-to-market. It can be seen that the product backlog was filled at the beginning of the project and then continuously processed. The average customer cycle time initially increases continuously as the processed requirements continue to age.

Cycle Time Histogram

In contrast to cycle time scatter plots, cycle time histograms do not analyze the development of the lead time over time, but concentrate on the statistical distribution of the lead time. The different cycle times are plotted on the x-axis, while the y-axis shows their accumulation. The cycle time histogram can provide particularly interesting information when recognizable clusters of tasks occur. In this case, a team can focus particularly on optimizing the cycle time of these specific groups of tasks.

As we can see, there were no tasks that were completed in zero days, which is perfectly logical and consistent. Half of the tasks had a cycle time of three days or less, while the 85% percentile is eight days. As shown in the cycle time scatter plot, 95% of the tasks are completed within the time window of the two-week sprints. At first glance, no task clusters are visible in this cycle time histogram. However, an analysis of the individual task types could reveal patterns.

Throughput Run Chart

A metric related to the predictability of a team is throughput. Throughput indicates how often a team completes and finishes a task. The chart plots the data similarly to the cycle time scatter plot. The x-axis shows the particular calendar date, and the y-axis shows how many tasks were completed on that particular day. Ideally, work flows evenly through a team and daily throughput is nearly constant. However, in the case of Scrum teams, throughput varies due to the sprint changes.

This chart shows us that the throughput of the team in the period under consideration was between zero and nine tasks per day. This of course includes many non-working days on weekends and holidays. The majority of days had a throughput between zero and three days, and a higher throughput was only achieved on a small percentage of days.

Throughput Histogram

The throughput histogram relates to the throughput run chart, like the cycle time histogram to the cycle time scatter plot. It does not show the distribution of the throughput over time, but the accumulation of tasks with respect to their throughput. On the y-axis, we see on how many days the corresponding throughput was achieved. Ideally, the work flows evenly through the team, and thus the throughput in this case should be nearly constant. A large scatter of data in the throughput histogram indicates a very uneven flow of work.

As we can see, 50% of the days have a throughput of one or no tasks, while the 95% percentile of days has a throughput of five or fewer tasks. Only 5% of the days have had a higher throughput, but there is no cluster with significantly higher throughput. However, the chart is also showing that the flow of work is not evenly smooth.

Work Item Age

The next interesting metric related to predictability and deliverability of a team is the age of the tasks in process. In the ideal case of a constant work flow, tasks only remain in a certain processing step for a certain time. If tasks in a step age at a higher-than-average rate, this is a leading indicator of increased cycle time. In this case, the team can take action to prioritize potential problems with that task at an increased level. A common tool for visualizing the age of a task is dots on the associated task card. Once processing has begun, another dot is added each day, thus visualizing the age of the task.

In the example, we see four tasks that have been selected for processing for five days but have not been started yet. Furthermore, one of the tasks has already been in review for four days. This long processing time in this work step could indicate an issue and should be investigated.

Furthermore, it is possible to visualize the age of the tasks on a certain day in the past. For example, we can see that one of the tasks has been in development for ten days. Since the age was also visible on the corresponding task card, the team could focus attention on this task.

Work in Progress Run Chart

The WIP run chart shows the development of the tasks in progress over time. In the ideal case of a constant work flow, the number of tasks currently being processed is almost constant. This avoids unnecessary task changes and waste, in the sense of lean management. In the WIP run chart, the time course is shown on the x-axis, while the y-axis shows the number of tasks in progress on the respective day.

As we can see, the number of tasks in progress varies greatly over time. The sprint changes of the Scrum team are also clearly recognizable. Before these, the number of open tasks dropped significantly; these were often still completed on time as part of the achievement of the sprint goal. Nevertheless, a lack of focus is particularly evident in the middle of the chart, as too many tasks were processed simultaneously or alternately without completing the other task first.

Cumulative Flow Diagram

The cumulative flow diagram is another way of showing the progress of work done over time. On the x-axis, the temporal course is shown again. The y-axis displays how many tasks of the team had passed a certain state of the workflow at a certain point in time. In the case of an ideal flow of work, the different trend lines move in parallel. This means that tasks flow into the team and are completed at the same constant rate. From the cumulative flow chart, conclusions can be drawn about both the work in progress and the cycle time.

The work in progress can be calculated as the difference between the number of completed tasks and the number of new tasks at a given point in time. Average cycle time is the time difference between the point when the amount of completed tasks reaches the same amount of new tasks. Thus, the vertical difference of data points at a given time defines the number of tasks in progress, while the horizontal difference of two data points defines the cycle time.

Final Thoughts

The use of a Kanban board alone does not allow any statement about the flow of work in the team, the predictability of delivery dates or the team performance. Core metrics of a Kanban environment can be analyzed with appropriate charts such as cycle time scatter plots or histograms, throughput run charts or throughput histograms, various charts related to WIP and the cumulative flow chart. The use of such efficient analysis methods can reveal various weak points in the development process. This makes it possible to live the motto “Stop starting! Start finishing!” with your team.