Cumulative Flow Diagram

The Value

The CFD, one of the most insightful, yet alienating agile charts out there. Many people find this chart to be fairly superficial, and to an extent you’d be correct.

Flow-based conversations are often very factual and data-driven, and the key to yielding value from CFD analysis goes beyond crunching the numbers and observing the peaks and troughs of each status.

Equally as, if not more important than the numbers are the stories behind them. What is the context that might have led to a blowout in the number of work items that were In Progress? Does it warrant a deep-dive discussion, similar to a retrospecitve? CFDs can be powerful tools for aligning conversations and identifying antipatterns,provided you use them correctly.

Hypothesis

We believe
that visualising the history of work items
and how they progress through the delivery pipeline
will enable managers and leaders to understand where the bottlenecks (or constraints) are in their delivery flow
We’ll know we’re right when said leaders can use this historical view to see where the bottlenecks are
and can identify where the root cause of these bottlenecks originate from.

Method

1. Identify scope of analysis using JQL query in Jira, or through collating a list of boards/projects on other platforms
2. Extract a data set using the platform's API
3. Cleanse the data using a KNIME script
4. Reorganise data to show each historical transition from one work status to another
5. Visualise the results using the d3.js javascript library

Insights

After trialling the Cumulative Flow Diagram in several environments and backgrounds, from large-scale SAFe PIs to individual flow-focussed Kanban teams, there have been several key themes identified once placed in front of the team:

• Organisations that work in siloed functions tend to batch up work, and maintain large holding queues. Especially in complex environments this increases the probability of escaped defects and backward movement through a delivery pipeline
• Conversely, teams that were cross-functional in nature tended to work in smaller increments with smaller queues. Those with a DevOps focus tended to be much further ahead in this regard as they had Continuous Integration / Continuous Delivery principles in mind when designing the delivery pipeline
• The actual root cause for the bottleneck was, more often than not, found earlier in the workflow. For example, a testing / release bottleneck could be attributed to poor practices introduced in the analysis or development portions of the workflow

Conclusion

The Cumulative Flow Diagram is deceptively simple to digest at first glance. Teams should always be on the lookout for repeated bottlenecks in their delivery workflow, but should be mindful that the actual cause of those blockages may lie elsewhere. As always this sort of tool should be used to initiate meaningful conversations, rather than shutting them down.

If you'd like to know how this visualisation could be implemented in your organisation, feel free to contact us!