Kanban is a lightweight method for evolutionary change management and is widely used for guiding and improving processes. While it does not prescribe concrete tools, a large variety of such tools have been developed. One such tool is the Cumulative Flow Diagram (CFD).
A CFD is a chart based on multiple metrics. A major improvement goal of Kanban teams is to stabilize and then reduce lead and cycle time – that is the amount of time it takes to finish a task. Using a CFD, a team can therefore determine its current state and detect whether it improves over time or not.
A CFD helps a team to rely on data instead of gut feeling and enables them to collaborate effectively by showing where to smooth out the flow and by limiting work to capacity. A far better method than simply adding more people to the team or working more hours.
Left: an avatar indicating the fallacy of relying on gut feeling instead of data. Right: definition of the phrases “lead time” and “cycle time”. The lead time represents the whole time from writing the idea down into a ticket until live customers using idea’s implementation – a finished feature for example. The cycle time refers to only a part of that process. Cycle time is the time between start of implementation and live deployment of a feature.
How do I create a CFD?
Many teams use cards, sticky notes, tasks or any kind of tickets on a board to organize themselves. In such a board they can see different process steps. There are at least three: “Backlog”, “Doing” and “Done”, but often more. An example of such a board is shown below.
A typical task board of a team contains many tickets in multiple process steps. Example steps are Backlog, Analysis, Development, Testing, Done. Tracking the amount of those tickets for each column on each day over time results in a data table.
To create a CFD, the team counts the amount of sticky notes on the board in each process step for every day. The result is a table containing data. From this data the team can create a stacked area chart with the X axis for the time and the Y axis for the amount of sticky notes.
Note that the amount of sticky notes is accumulated. So the size of the areas in the chart increases over time. It is easy to do this using a charting tool like Excel or Google Spreadsheets.
A typical CFD chart generated in a charting tool with the data from the table. Each color area represents a process step with the amount of tickets in that step over time. As the amount of tickets is always accumulated the chart grows over time.
What does the CFD tell me?
Imagine a CFD would end up looking like the chart below. The amount of sticky notes in the team’s backlog is growing. This means that they have much more ideas than they have capacity for implementing. The team can resolve this by throwing away ideas more aggressively using more thorough and regular prioritization.
A CFD chart showing an increasing backlog size.
Now imagine another scenario where the team very quickly starts implementing many ideas. The problem here is that they are starting things much faster than they finish them. The CFD notifies the team about this through the size of the Work in Progress area, which is the combined amount of all the steps between Backlog and Done.
A CFD chart showing an increasing Work In Progress area size.
Over time this will lead to a less stable system and to a slowdown. This slowdown can be seen in the CFD below. It reflects the increase of the average cycle and lead time. But the team could do something to fight this, for example add WIP limits. When WIP limits are adhered to, the team should soon notice a change back to shorter cycle and lead time.
The white annotations in this CFD show different cycle and lead times at two different time periods. One set of arrows denotes a longer time due to the increasing parallel work in Development (yellow) and slow progress in Testing (blue).
Alongside with being a direct metric for lead time, cycle time, WIP and backlog size, the CFD also has a relevance in diagnosing the Kanban system under observation. The team can deduce the stability of their Kanban system by looking at the size of the areas over time. Do the areas progress in parallel size? Are there any spikes or changes? Using the same data the team can identify whether their system is stable, their process is reliable and their technical base is healthy.
In a paper from Large Scale Scrum (LeSS) discussing the Queueing Theory, the effect of different batch sizes is summarized as:
“batch size, size of requirements, and utilization levels affect queue size and cycle time in nonlinear random ways that are not obvious—throughput can get slow if not understood.”
Disturbances in the chart therefore indicate traffic jams, such as a growing input queue or the mentioned arrival of work in large batches.
Another good idea is to introduce a cadence in form of a measurement cycle, for example two weeks or a month. This is quite similar to iterations (or also “Sprints” in Scrum). It helps to detect problems early and enables the team to plan experiments for a certain time frame with measuring the change. One experiment might be the already proposed addition or modification of WIP limits. A nice summary for why WIP limits are beneficial can be found in the LeSS handbook:
“WIP is one of the wastes in lean thinking, because it delays a return on investment, hides defects, reduces transparency, among other problems. And reducing WIP levels exposes weaknesses. But, unfortunately, there is no guarantee in software development that reducing WIP will automatically reduce average cycle time.”
An example CFD chart over a longer time. This team uses weekly iterations. In the grey boxes the events or changes of the team are annotated.
In an ideal world, a CFD has constant and parallel lines. Increases and drops are undesirable and indicators for changes or other influencing factors, such as blockers or accumulating queues. The global growth in the chart varies from team to team, because the environment, speed and throughput of every team are different.
For reliable data, it is important to use values from equal intervals. Measuring on a daily basis makes much sense in the beginning. Later, one can change this to weekly measuring to prevent the chart getting too noisy with many data points.
Similar ticket size play an important role in ensuring consistent lines. Tickets should have roughly the same size, because only the amount is relevant for this metric and not the particular effort.
In summary, using the CFD to monitor stability enables the team to do analyses of their metrics, do estimates, communicate forecasts and, very importantly, experiment with changes to their system. Because, after all, quoting Dr. Klaus Leopold:
“Kanban means to always run a changing system.”
We put the essence of this blog post together into a free poster that you can put onto a wall for educational purposes. You can download it here:
- Training Kanban anwenden – KMP I, Klaus Leopold, LEANability, 22. Juni 2017, https://www.leanability.com/de/details/kan-2017-06-fra/
- Kanban and Scrum – making the most of both. Henrik Kniberg & Mattias Skarin. InfoQ. ebook. 2010. https://www.infoq.com/minibooks/kanban-scrum-minibook
- Kanban in der IT: Eine Kultur der kontinuierlichen Verbesserung schaffen. Klaus Leopold, Siegfried Kaltenecker. 2. Ausgabe. Hanser Fachbuchverlag, 2013.
- Marcus Hammarberg and Joakim Sunden. 2014. Kanban in Action (1st ed.). Manning Publications Co., Greenwich, CT, USA.
- Little’s Law und Systemstabilität: Ein Interview mit Daniel Vacanti. Leanability Blog. Klaus Leopold. Aug 6, 2017. https://www.leanability.com/de/blog-de/2017/08/littles-law-und-systemstabilitaet/
- Team Kanban, Scaled Agile Framework, 28 September, 2017, http://www.scaledagileframework.com/team-kanban/
- Was ist ein Cumulative Flow Diagram, microTOOL, 12. Oktober 2017, https://www.microtool.de/was-ist-ein-cumulative-flow-diagram/
- Cumulative Flow Diagram | Wall-Skills.com, Corinna Baldauf, Dec 13, 2013, http://wall-skills.com/2013/cumulative-flow-diagram/
- Cumulative Flow Diagram, Pawel Brodzinkski on Software Project Management – Lean, Agile and Kanban. July 15, 2013. http://brodzinski.com/2013/07/cumulative-flow-diagram.html
- Queuing Theory, 2018, The LeSS Company B.V., LeSS Principles, https://less.works/less/principles/queueing_theory.html