What is a Cumulative Flow Diagram, Really?

My colleague Julie Wyman and I have been presenting on flow metrics for clients and at conferences. In our experience, we find that measuring flow provides rich insight into the way a team works. The metrics can call attention to problem areas that need improvement or validate the team’s sense of how their improvement actions have affected their work. One of our favorite metrics is the cumulative flow diagram (CFD), a way to visually represent how work moves through a process.

Here’s an example CFD for a team with a simple “To Do,” “Doing,” “Done” workflow.

In this example, we track the team’s work, day by day:

1. The team starts with one item in “Doing” and two remaining “To Do;”
2. The team starts work on another of the “To Do” items;
3. The team finishes one item and moves it to “Done,” starts another “To Do” item, and adds two more items to its “To Do” list;
4. And the team completes another item and moves it to “Done.”

We define the CFD as a stacked area chart of work items in each status over time. By this definition, the vertical thickness of each band is the work in progress (WIP) in the workflow state it represents. The horizontal width of a band gives you a sense of the average cycle time for items moving through that workflow state.

After one of our sessions, we got some feedback that this wasn’t quite correct. Daniel Vacanti’s book Actionable Agile Metrics for Predictability calls this method “dubious.” Instead, he defines the CFD as an area chart of cumulative items arrived to each status over time. Here’s a comparison of CFDs for our team above using the two different definitions.

If you can’t tell the difference, that’s because there isn’t one! If all goes according to plan, the two definitions give identical results. The vertical thickness of a band in Vacanti’s definition – the cumulative items to enter a workflow state minus the cumulative items to enter the next one – is the same as the state’s WIP.

But what happens when things don’t go as planned? Vacanti identifies two cases where the definitions yield different outcomes.

Backward Flow

The first case is when a team’s policies allow items to move backward to a previous workflow state. Let’s say our team moves two items into “Doing” on day 2. On day 3, one of those items is completed, but an issue is discovered in the other. The team elects to send the item back to “To Do” for further preparation, and on day 4 it comes back to “Doing.”

Here the difference is obvious. With our WIP definition, we see the “To Do” state expand downward on day 3 as it reclaims the item from “Doing.” Under Vacanti’s, we don’t see anything – only that forward progress is stalling. The problematic item doesn’t enter a new state, so no new entries are recorded for it.

Which definition should we apply? It’s true that nothing “cumulative” can ever decrease, so we shouldn’t expect to see lines decreasing in a true CFD. The line for “Doing” dropping in the WIP definition, then, is a red flag. But it should be! Identifying issues like items moving backward in a workflow is the reason we measure flow to begin with. The WIP-based CFD shows the situation for what it is, while Vacanti’s gives us no indication of the problem. I’m fine gently stretching the rules to get that insight, so I prefer to use the WIP definition.

Abandoned Work

The other case is if a team abandons work. Consider an example like the one above, but instead of the item moving back on day 3, it is abandoned. Assume the issue is so serious that the team agrees the work is not worth completing.

If we track WIP, the “Doing” state moves downward as before, but this time “To Do” falls as well. Following Vacanti’s definition, progress stalls as before. The same argument in favor of the WIP definition applies here – I would rather see the issue than obscure it. But also note that the “Doing” band in the Item Entries version has picked up an extra work item that will never leave! If this case happens again, the band will only grow and grow, ultimately rendering the chart useless.

You won’t see this graph in Actionable Agile Metrics, though. Vacanti makes a tweak to the rules that sidesteps the issue. He defines the “Done” line on the CFD as cumulative exits from the system, not entries into “Done.” This is a reasonable change – some users of the WIP definition use it as well. When done that way, both definitions represent this situation the same way:

Both definitions may have problems with this situation but work fine in actual use. As a result, I don’t find this scenario a compelling case for either definition.

Skipping Ahead

There is a third case where the definitions differ that Vacanti doesn’t consider: when an item skips over a step entirely. Say that on Day 3, our team completes one “Doing” item, but also discovers that a work item in “To Do” has already been addressed by another team. They mark this item as complete right away, without ever considering it in progress.

Tracking WIP, we see what we would expect: two items move into “Done,” one remains in “Doing.” But Vacanti’s method doesn’t capture the skipped item. It shows two items moving into “Done,” but acts as if both “Doing” items moved, seemingly leaving behind an item in “To Do.” Not only is this misleading, but if this continues to occur, our “To Do” band is in danger of growing indefinitely, just as “Doing” could in the prior example. Again, I find the WIP definition to be more valuable for learning about a team’s workflow.

Putting it Together

My analysis shows that the definitions are equivalent for a “normal” flow of work and one special case. I believe there are two other cases where charting WIP seems preferable to charting entries (and exits). In addition, I’ve found the WIP definition to be easier for teams to understand and use. In my view, that makes the WIP definition the clear winner.

It may be true that by charting WIP we are not, strictly speaking, creating “cumulative flow diagrams” in the sense the term was originally used in contexts like manufacturing. But as we’ve seen, a rigid application of those rules has the potential to do more harm than good. And it seems a shame to throw out the concept or invent a new term, particularly when the WIP definition is already in common use in the Lean-Agile space. After all, it’s the WIP definition that’s found on Wikipedia, in the getKanban game, and even our Kanban Management Professional course. And it’s finding real-world value, not being right on paper, that Agile is all about.