How to spot and fix issues with a cumulative flow diagram

A cumulative flow diagram (CFD) is a visual representation of how your system is performing. A CFD is a powerful tool, and it can tell you much about the health of your system. You’ll see patterns around the flow of work and issues — if you know what to look for.

In the first blog article, I outline some caveats and words of warning. As I help and not confuse, here is one important point on the next chart: I’ve not wanted to make the chart below too wordy. Technically, wherever you see the word ‘average’ you should read ‘approximate average’. I’m not going to go into why here, though chapters 4 and 5 in Daniel Vacanti’s excellent Actionable Agile Metrics for Predictability explains it better than I ever could.

In this second blog, I’ve outlined some of the most common problems and warning signs. I’ve also included some questions a team could use with to discuss problems with their flow. I’ve used many of these as retrospective conversations. Given a CFD only looks backwards, it’s best used in that Scrum event, rather than planning.

An important reminder is that a CFD will show you variability in your flow. Variability is natural — you should always expect it in your system. Therefore a CFD to an extent will reflect that variability back to you. The charts below are occurrences observed with teams I’ve worked with and some of the questions we discussed together. Using a CFD as a conversation tool helped us to expose areas of improvements, all with the aim of achieving better flow.

Widening bands

You want your arrival and departure rates to run in parallel with each other for a healthy flow. If you start noticing some of the bands in the graph widening, it means your work in progress (WIP) is increasing. The likely cause is a WIP limit being broken somewhere, causing too much work to come into the system.

Setting and keeping WIP limits is essential to help the team focus on a few items at a time. Little’s Law tells us that if you increase your WIP without finding a way of increasing your delivery rate, you will see your cycle time increase. Decrease your total WIP by setting limits and you’ll likely reduce your cycle time. WIP limits are an effective way of regulating flow.

If you’re not familiar with Little’s Law, Daniel Vacanti sums it up quite nicely:

Three of these metrics (Work in Progress (WIP), Cycle Time, and Throughput) are intrinsically linked by a very straightforward and very powerful relationship known as Little’s Law:

Average Cycle Time = Average WIP / Average Throughput

Even if you’re not good with numbers, this makes sense if you think about it. If you have more work in progress in your system, this will cause a team to context switch and multitask. Productivity will drop as the team will juggle multiple items simultaneously, meaning everything takes longer.

Instead, set WIP limits to focus on one or two items at a time. By setting and keeping to WIP limits, you will stabilise your flow, hopefully causing your cycle time to drop.

If you’re seeing widening bands, take action before your cycle start to seriously increase. Some of the questions to ask:

• Do the team have WIP limits and are they sticking to them? What are your policies for temporarily breaking WIP limits? Do you need to adjust (ideally lower) your limits?
• Are there external pressures? Are tasks being pushed on the team by management instead of pulled by the team?
• Are there issues with your system at specific points? Are you experiencing issues with your flow?

Narrowing bands

Narrowing bands will probably be showing you the opposite of widening bands. Too little work is flowing in or to specific states within your system. It is possible items are jumping a state in the system, Or there could be a blockage that is starving another part of your system.

If you’re seeing narrowing bands, look out for the following:

• Have you set up your system in the best way? Are items able to flow through with clear policies in place? Is every state needed?
• Do you need to set up queuing states within each state, for example, ‘doing’ and ‘done’? By setting up done stages for each state, you can more easily identify blockages and other issues with your flow.
• Are your WIP limits right?

Flat lines

If you spot flat lines on your CFD, it means there have been times of no activity for that state in your system. The longer the flat lines are, the longer the period of inactivity. Flat lines :

• Is there a reason why there would be a period of inactivity? Is there a public holiday or series of absences in the team?
• Is there a blockage somewhere in the system which is affecting flow?
• Do you have items aging above of your service level estimation (SLE). Your SLE will tell you on average how long it takes items to flow through your system.
• Could you improve one part of the system to improve your overall flow? For example, if testing slows things down, could you put in new testing systems to speed things up?

A staircase

If your CFD looks like a staircase, it probably means you’re delivering your work in specific batches or cycles. While this isn’t necessarily a problem in the short term, it could be holding things up downstream in your system. It can also create dependencies within your system, as people wait for a batch to become available before they start work.

Longer term, this is problematic as it can become harder to predict flow and estimate how long work takes to complete. From a product point of view, you want to get your increment out and in front of customers as early as possible. That way, you can start to get feedback and validate your assumptions around value.

Some questions you can ask:

• What can we control as a team to even our flow and release more quickly? What conversations do we need to have with other teams if this is out of our control?
• Can we move to better and faster ways of testing and releasing?