Disclaimer: I’m practicing my English writing skills so if you notice any mistakes please feel free to contact me 😅
In this article, I’ll show you guys what type of information (and charts) I use with the teams I work with. But first, I’ll give you a little brief about the 3 main Kanban metrics that you need to collect and have in hand before analyzing the data.
Using the definition from The Official Kanban Guide:
- Lead time:
It’s the time it takes for a single work item to pass through the system from the start (commitment point) to completion; - Throughput (or delivery rate):
It’s the number of completed work items per unit of time, such as features per week, training classes per month, or new hires per month; - WIP (work in progress):
It’s the amount of work items in the system (or a defined part of it) at a certain point in time;
I won’t get into specific details about the above but if you want to know more I recommend you this: What to Measure and Why: Kanban Metrics (Nave)
I’ll start with the 🔢 throughput (or delivery rate).
Weekly throughput
The first chart I like to use is the weekly throughput, so I can visualize if the team is delivering frequently:
But what is the team delivering? How many work items are 💎features? What about 🐞bugs? So usually I break down the delivery by work item type:
Weekly throughput by work item type
Looking at this chart I can notice that this specific team was working with support items at the beginning and now they are dealing with improvement items (in our context it’s engineering and code improvements).
- Well, maybe we are dealing with refactoring?
- Is our codebase getting more efficient with all these improvements?
In the first 18 weeks (or 4 months) the delivery average was 2,3 work items per week. Since then, we are delivering 4,7 work items per week.
- What happened?
- What caused this difference?
In the last 3 weeks we delivered 3 items. Again, you can ask the team:
- What happened?
It’s important to ask the teams these questions to bring them together looking at all these data.
When you have the delivery rate and the specific date periods, you can also track the average throughput in the period and the delivery rate per day:
Average throughput in the period
In this example, it’s total throughput in the period/qty of weeks = 114 items / 30 weeks = 3.8 items per week
Delivery rate per day
Total throughput in the period / qty of days = 114 items / 150 days = 0.76 items per day
Or average throughput (3.8 items) / 5 days = 0.76 items per day (to make it easy 😅)
Every team has a different context, so be careful not to be too judgmental in your analysis and how you talk to the team. The idea is to analyze the data and not the people.
I like to visualize the throughput by month, too:
Monthly throughput
Looking at the chart above, you can see that the team never delivered more than 12 items in the first 7 months together.
So what happened after that?
- What caused you to jump from 12 items delivered to 27?
- Is the work batch smaller?
- Has any expedite/urgent work happened?
- Do we have more people on the team?
So with these 2 charts (weekly and month throughput), you can analyze different types of suppositions you have.
When you split your deliveries by week and month maybe you want to see the total of deliveries by work type. So, the next chart is this one:
Deliveries by work type
As you can see the team is indeed working on lots of improvement.
As an alternative, you can use the pie chart to see the % too, but usually, a pie chart with more than 5 categories is bad to visualize:
Now let’s talk about 🕔 lead time.
Lead time control chart
This one is a good visualization of each task lead time, I use it together with the one below:
Lead time histogram
Histograms are great to answer the question ‘usually, the team delivers an item in how many days?’ (not only this question, ok?) and you can cross a line in certain percentiles to have a better idea of your data set.
Looking at the chart above, you can see the p75% line is at 12 days. What does it mean?
👉 It means that this team delivers an item in 12 days, 75% of the time.
Usually, I like to see the average, mean, p60%, p75%, and p90%.
There are different patterns of a histogram, you can check it here:
- 🔗 Frequency Distribution: Histogram Diagrams (Nave)
- 🔗 Analyzing the Lead Time Distribution Chart (Connected Knowledge)
Lead time by work item type
Drilling down in the lead time numbers, I like to use the 75th percentile because it gives you a little more certainty about your delivery patterns. You can use the average too, but averages usually are a bit more sensible to outliers and this can skew your data set.
Let’s take a look at the chart above, you can notice that ‘support’ items have a 75% chance of being delivered in 4 days. Stories, 75% of the time, are delivered in 20 days.
So when you break down your work items by type you will have a more precise analysis, just like we did analyze the delivery rate.
Time in status
I like to use this one to have a better idea of where our flow’s bottlenecks are. It’s a great tool to see if your workflow has a pattern of ‘tasks are always more than X days in this column’.
💭 My insights looking at the chart above:
- Most of the items went quickly through our flow, so they were created, pulled into dev, and delivered;
- Despite the high customer lead time in the 6 outlier items, the system lead time was low, so the work spent more time in ‘waiting’ stages before commitment (which can be a problem, too)
Backlog aging chart
I like to use this one to visualize how old my backlog items are. As we can see above, some items are more than 330 days in the backlog.
When you look at something like this, you can ask the team: Is this work item still necessary?
Sometimes when you have an extensive backlog, you certainly will forget about less prioritized items. This is an excellent chart to start an explicit policy like ‘start discarding things that we know we won’t do’.
Maximizing the work not done is a thing.😀
Average weekly WIP
This is one of the most important charts here. It will show you how many items are in progress (or after the commitment point) on average per week. It’s good to help you visualize if the team is overwhelmed with work on a weekly basis and the moving average.
You can see that this team had a big spike in WIP on May-21 and July-21. After the last spike, the moving average went down.
- Did you limit your WIP?
- Maybe the team is working on pair programming?
I combine the chart above with this one 👇:
Work item input vs Throughput vs Average WIP
I like to use this one to compare how many items the team is pulling and how many are being delivered. It’s a good tool to visualize the balance between work items in and out of your workflow, and the average WIP.
Cumulative Flow Diagram (CFD)
I don’t use the CFD as much as I should, I think. Usually, I look at it but I keep to myself because it can be a little difficult for the team to understand what it means. Of course, it depends on the team’s maturity, if they are used to looking and understanding the flow metrics maybe you should show them frequently.
The CFD is one of the best ways to see a lot of patterns in your team workflow and can help you with so many thing, here is a good source to help you:
Well, I think that’s it! This article became longer than I planned, but I hope it can help you to start looking and analyzing your team’s deliveries.
If you have any questions, you can 💬 contact me on LinkedIn.
