Flow Metrics @ tb.lx series: Meet the Cumulative Flow Diagram
Welcome to Flow Metrics series by tb.lx! This is our fourth and final article in the flow metrics series, and the third one in which we deep dive into our last metric: the Cumulative Flow Diagram.
(Read the first article here to learn more about what flow metrics are and to meet our former Agile Specialist Breno Campos, and the following two articles to learn more about throughput and Leadtime and Leadtime Breakdown ).
We are concluding our deep dive on flow metrics at tb.lx, by looking into the Cumulative Flow Diagram (CFD). A cumulative flow diagram is a tool used in queuing theory. It is an area graph that depicts the quantity of work in a given state, showing arrivals, time in queue, quantity in the queue, and departure. This is the most challenging and advanced metric since it provides a holistic overview of the team, historic performance, and health.
Let’s get down to the nitty-gritty of the metric and how it is visualized on a graph. This example data represents the work of a team. The X-axis shows the timeline. From left to right, you will find the team’s kick-off until the last day. The Y-axis indicates the number of items. We need to make some calculations to get the different lines that separate the areas from each other. The areas are ordered according to the structure of the workflow. Each item starts at the top (Backlog) and follows the flow to the bottom (Done). The area between each line and the bottom shows the number of items currently in their actual status or those already left behind. Putting it in the Kanban board context means that the item is currently in this column or status. In the case of the Backlog, that would mean that this area shows all items that have ever been created in this project.
There are some peaks of “Ready” (marked red), meaning that the team regularly commits to a large batch of items. Since we are working with Kanban, this is a trend we should expect, since there are some “flow-feeding” events, like Refinements, Replenishments, etc. If we cannot reduce this amount until the next event, we should consider adjusting this occurrence since committing to more work than the process can handle is unhealthy. As a result, we would lose credibility and reliability by committing to more items than we can deliver. A good practice we follow and recommend is not having a regular occurrence of these “flow-feeding” events, but rather, a defined threshold of refined items. If the number of refined items drops below the threshold, we meet to align internally. This helps us be leaner and reduce the number of meetings we have.
The other extreme is to have no items we can work on. In the chart context, this would mean no “Ready” area. The main challenge is to ensure that we always have an amount of items in this column that we feel comfortable with. Since this is a unique number for every team, you need to experiment with it, and based on your experiences, you can set the threshold higher or lower.
Another thing we can monitor with the help of the CFD is if the team is paying attention to the work-in-progress (WIP) limit. By limiting the WIP, we ensure that we won’t lose track of topics we are working on, and hop from topic to topic without having finished anything. If the team is paying attention to this limit, the “In Progress” area should never get bigger than this aligned value. In general, the CFD could also be used to check if we are creating a bottleneck somewhere in the process. If that’s the case, this will increase the area in this chart. As we can see above, in the example we give this is not the case, since the “In Progress” and the “In Review” are stable over time.
Checking the size of each area regularly, enables us to intervene earlier. We can also always understand what is going on in the team and check where the vulnerable points of the process are.
As we can see in the image above, when we increase the work in process, represented by the red box, it impacts our capacity to deliver and focus that impacts our delivery pace, we can confirm that by checking how the area becomes flat after the peak, represented by the green box. This shows us that after a WIP (work in process) increases, we affect the throughtput and deliver less.
It’s simply Little’s Law at work.
According to Little’s Law, the Leadtime is affected by the WIP and the Throughput. Meaning, that the greater the WIP and our time to deliver (leadtime) , the higher our delivery capacity is, and the throughput decreases. We can see that in the graphic. When the line became horizontally flat, we were taking more time to deliver (increasing the leadtime), and since the line is not bumping up, it meant we were not delivering service (throughput).
One of the key points we led up to presenting throughout the series, is Little’s Law. Little’s Law will be something you’ll hear about a lot once you start your studies about metrics, Kanban, and Lean.
We hope you enjoyed our flow metrics series and can apply the key learnings from the articles, as an agile team, to bring them into your daily operations. Remember, every team is different, and every metric applies differently to your work.
This series of articles were written with the support of Breno Campos, a former Agile Coach at tb.lx, and Benedikt Heinz, a dual industrial engineering student at Daimler Truck, that was previously on an international assignment at tb.lx.
