When we talk about making the work visible, there are two key aspects - what is the work and how is the work progressing. In this article, we are going to focus on how the work is progressing. Specifically, we are going to look at Cumulative Flow Diagrams as a means of visualizing work progress.

Cumulative Flow Diagram (CFD) overview

A CFD is a chart that shows the cumulative amount of work items in different stages of a workflow over time. It’s a visual representation that highlights how work flows through a system. It allows us to quickly garner insights into productivity, identify bottlenecks, and assess process stability.

Many teams use burn-up or burn-down charts to help them track progress. A CFD not only allows the team to track progress, but also gives a more full picture of workflow health and process stability.

These days, most work tracking tools will automatically generate a CFD for you, so I am not going to get into the details of how to create one on your own. At a high-level, if you need to hand-create a CFD, you simply track the cumulative items in each stage of your workflow at approximately the same time every day and then chart that data on a stacked area graph.

A basic CFD looks like this:

In our example, we are tracking five different states for each work item; “Ready to Start”, “In Progress”, “In Testing”, “Ready for Approval”, and “Deployed”. Each state represents a key point in the workflow from initial readiness through to final deployment. You may be tracking more or less, depending on your process and what issues you may be trying to diagnose.

In general, I suggest teams track each of their major stages and any wait states they think might happen. For example, it is common for a story to be ready and sit in a queue (sprint backlog) for a while before it actually gets worked on. Having this wait state provides clarity - it doesn’t look like we are taking longer than reality to ready the story and it doesn’t look like we are taking longer than reality to develop the story. Instead, we can see that stories wait between these two stages.

Let’s take a closer look at how to read this thing.

How to read the CFD

Work Status

Let’s start with something simple. Let’s take a look at the work that is completed and the work that is not yet complete. In the above chart we can see at any moment in time how much work is complete and how much is yet to be done. We can also see how the work has progressed over time. This is very much like a classic burn up chart, but with more information baked right in.

Work in Progress (WIP)

We can see how much work has been in progress (WIP) over time. In this example, the team considers “In Progress”, “In Testing”, and “Ready for Approval” as In Progress. The team considers every state from when development starts to right before deployment as Work In Progress. The specifics may differ for your team, but the general concept is applicable. You can look at the chart and readily see over time when and how often your team violated your WIP agreements.

Lead Time

In the above chart, we can see the average lead time for stories completed within an iteration. Choose any point where work has crossed from WIP to done and track back to where the work first appeared and this is the average lead time for the items delivered in that iteration. Essentially, it is the time it takes for a story to go from concept (or in this example, ready for development) to delivery. Imagine it as the journey from a story’s inception (“Hey, wouldn’t it be nice if…”) to delivery (“Hey, isn’t that nice”).

Using the graph above, we can see that the work completed in the 8th iteration had an average lead time of eight iterations and the work completed in the 10th iteration had an average lead time of seven iterations. Lead time provides a simple way to roughly determine when a story will be completed. It is not precise, but if we know on average a story has about seven iterations of lead time and you want to know when this new story will be completed, it is safe to say it will be ready in about seven weeks. Now, if you want to expedite the story and have it jump ahead in the backlog, you’ll need to know the average cycle time instead.

Cycle Time

Cycle time is essentially the time between the start of one stage and the end of the same or a subsequent stage. In our example graph, we are interested in the cycle time for our delivery team (from when it gets pulled into “In Progress” through to when it leaves “In Testing”). In our sample scenario where we have moved an item to the top of the backlog, we’d need to look at the cycle time from “In Progress” through “Ready for Approval”. In this case, that value looks to be about three iterations. So it is safe to say the average story takes about three iterations to get all the way through development and testing into production.

Note - Lead Time is essentially cycle time for the entire process.

Scope Change

A CFD also includes a clear picture of scope changes, be they increases or decreases. This is often not the case with a burn chart or other commonly used charts. But with a CFD, we can see what happens to our scope and when. In this example, we can see that another fifty units of work were added to the backlog at the start of the fourth iteration and then another five units at the start of the eighth iteration.

CFD as a forecasting tool

I highly recommend you take a look at the work of the folks over at Focused Objective and their forecasting tools, but in a pinch, a CFD can serve as a reasonable lightweight means of forecasting.

One technique is to run a trend line, much like a burn up chart. In our example, “Ready to Start” represents the scope of work remaining and “Deployed” represents the work completed. Running a trend line on “Deployed” to see when that crosses the top of “Ready to Start” gives you a rough estimate of when the scope of known work might be complete.

Another technique, which we covered already in this article, is to use the Cycle Time of our work states to give a sense of how long a story might take to complete if we started on it today. You might notice that this is independent of the “size” of the story. There’s a whole debate to be had here and that is definitely material for some other article. Regardless - what we’re talking about here is some simple techniques we can use to get a high-level feel.

CFD as a diagnostic tool

A CFD can help identify issues in the flow of work. We can see if the average cycle time or lead time is longer than desired. We can see how our scope of work relates to our rate of delivery.  And we can see if there are bottlenecks in our flow.

Let’s dig into the bottlenecks a little bit more. The following is a graph of the throughput for a team over time. 

From this graph, we can see that the team’s throughput is highly variable and that it seems to spike at times. There doesn’t appear to be a consistent pattern beyond low throughput for a few iterations followed by a huge spike. We know there is an issue, but we don’t necessarily know what it is.

Now let’s take a look at the exact same data, but in the form of a cumulative flow diagram.

This gives us a clue as to what might be happening for this team. In this case, work seems to be moving through development (“In Progress”) and testing (“In Testing”) at a pretty consistent rate, but then it gets bottlenecked in “Ready for Approval”. We now know where to look more deeply. In this case, we probably have enough information to resolve the issue by adding additional approvers or setting a clear SLA on approvals.

In other cases, we might identify a bottleneck, but not have enough data to know what to address. Say, for example, the bottleneck is in “In Progress”. We might choose to add a few lanes such as “In Dev”, “Waiting for PR”, “In PR”, “Waiting for re-work”, and “In re-work”. This would likely allow us to evaluate where the bottleneck is during the “In Progress” stage, enabling us to have an informed discussion about how to address the problem.

Note to the governance wonks

A team needs to own their process and tools within reason. I get that the company needs standards. I get that there are compliance concerns and that it is highly important that people follow a standard process. I also get that these processes can be overly prescriptive and calcified, limiting an organization’s ability to learn and adapt.

Here’s my suggested compromise - establish a baseline set of states that every team must track per the process standards. Maybe it is the ones we used here in this example, maybe it is as few as “Ready”, “In Progress”, and “Done”. You can figure that out. I suggest few rather than many. I suggest one set that applies to all teams rather than numerous sets that are contextually specific.

Then, allow teams to add and remove states to their flow as needed. Tools like JIRA allow you to do this rather easily.

Go get you a CFD

Hopefully, this helped you see how CFDs can be useful for teams that want to understand and improve their workflow. They provide a snapshot of the team’s overall productivity, allow for better-informed decisions, and help to continually refine processes.

If you aren’t already using CFDs, I suggest you get started. Many tools generate them automatically, making it easy to start seeing the benefits.