How to Actually Read a Cumulative Flow Diagram

ISSUE 04: This Week: Explaining CFD through a real worked example.

A Cumulative Flow Diagram is older than most of the frameworks built on top of it. The earliest reference dates to the 1960s, when it went by a more literal name: a Cumulative Arrival and Departures Diagram. Everything else- WIP, Cycle Time, Throughput- is a measurement taken off those two lines.

In 1961, Dr. John Little coined a relationship that holds for any queuing system:

The average number of items in a queue equals the average arrival rate multiplied by the average time an item waits.

Rearranged for flow work, it reads: Cycle Time equals WIP divided by Throughput.

Little illustrated the result with a wine rack: keep 100 bottles in it on average, replenish at 2 bottles a week, and a bottle sits in that rack for 50 weeks on average, a fact you can know without ever tracking an individual bottle's arrival or departure date.

Move one, and at least one of the others moves with it, whether anyone intended that or not. The practical result of this is that when Cycle Time is too long, the fix isn't to start more work sooner. It's to lower WIP. Starting more work to compensate for slow finishing is the intervention Little's Law predicts will make things worse, and it's also the intervention most under-pressure teams reach for first.

The top line of a CFD represents cumulative arrivals to a process, and the bottom line represents cumulative departures. A CFD can never go down. To build a CFD by hand, you physically count how many items sit at each step right now and plot that number at each reporting interval. That approach breaks the chart, because a snapshot count only tells you what's present today. An item can leave a state, and the headcount there drops.

Let’s take a hypothetical example of a team tracking its own CFD through August and September. On a given date, the vertical distance between two lines is the Work In Progress between those two steps. On September 1st, the top line sits at 520 items and the bottom at 450, for a WIP of 70.

The horizontal distance is Cycle Time, and it's read by drawing a line backward from a point on the bottom band until it hits the top line. From September 1st on the bottom, that line crosses the top on August 15th, 17 days earlier. By convention, we add one day, since a Cycle Time of zero would understate an item that took real time to move, putting the reading at 18 days. The items that started on the top line on August 15th aren't necessarily the same items that finished on the bottom line on September 1st, so this is a good estimate of average Cycle Time.

The slope of any line is the exact Average Arrival Rate for that band, and the slope of the bottom line alone is the exact Average Throughput.

A CFD only shows what has already happened. A chart with a projected line drawn off the end isn't a CFD anymore. Forecasting the future from this data means running something like a Monte Carlo simulation over the historical record.

The chart above is illustrative:

An Arrival Rate of 4 items a day against a Departure Rate of 3 means work is entering the system a full item a day faster than it leaves. As arrivals kept outpacing departures, WIP grew and Cycle Time stretched right along with it. A widening band is visible.

Four Common CFD Patterns

The figure below describes four common CFD patterns:

Bottleneck: a band widens steadily because work enters that stage faster than it leaves.

Starvation: a band narrows sharply because there's nothing left to pull downstream.

A jagged, batch, or staircase pattern: usually means work is arriving in chunks rather than flowing continuously.

And a complete stall: nothing is entering or leaving that stage.

One Project, Four Patterns

Let’s take a fictional 28-week platform rebuild with Design, Development, Verification, and Done as workflow stages.

Weeks 0 through 6, Development sits completely flat. Developers have no work, while the Design band above keeps climbing. (Mechanics: legacy hand-off process; Culture: No one in the team is authorized to start anything unless a sign-off is provided. A team that trusts a senior engineer to make a call. A team that routes every decision through a committee.

Weeks 6 through 14, Development finally clears its backlog, and the band widens fast. Development work is entering faster than Verification can absorb it. A “throw-it-over-the-wall” culture. As soon as the code merge finishes, testing is somebody else’s problem.

Weeks 14 through 22, Verification widens further, but there is nothing completed. Done is flat for two weeks, then jumps, then flat again, then another jump. This pattern shows a monthly change advisory board that approves releases on a fixed schedule regardless of how much is ready to ship.

Weeks 22 through 28, Development narrows sharply. The senior engineers who could unblock new work got pulled onto the next project. The remaining team keeps finishing the pending assigned work, which is why Verification and Done keep climbing, but almost nothing new enters Development. The work is winding down toward completion.

Four patterns, four different root causes, and none of them showed up in a status report that just said "on track" or "at risk." That's the case for reading the chart itself instead of a summary written about it.

SCHLENK, a chemical manufacturer, is documented in a case study published by Businessmap. Their R&D team read a widening gap on a CFD alongside a cycle-time scatterplot, responded with WIP limits and a tighter review cadence, and cut cycle time at the 85th percentile from 110 days to 44.

What about Backlog? The Band Most CFDs Get Wrong

A backlog is a holding pen for candidate ideas, not committed work, and a CFD's top line means cumulative arrivals; if every item counted in it has entered the process as committed and work has started.

Adding a backlog band would mean that the top line stops tracking arrivals and starts tracking intentions and options, most of which are not committed, have no agreed scope, and have no real start date.

Cycle Time gets measured from a date that doesn't reflect when real work starts, which drags the average down and makes the process look faster than it is.

Vacanti states the rule plainly: "commitment does not happen until a team actually has capacity, and prioritization does not happen until the time of commitment."

A backlog is "merely a convenient container" for ideas waiting on both. Until an item clears that bar, it isn't an arrival, and a chart that counts it as one isn't a CFD.

Reading a CFD, a Lead Time distribution, and a Run Chart well enough to catch a problem before it costs a sprint is a taught skill. Almost nobody arrives with the intuition already built in.

provcraft.com

#CumulativeFlowDiagram #FlowMetrics #KanbanSystemDesign #LittlesLaw #AgileDelivery #DeliveryManagement #WorkInProgress #CycleTime #KanbanMethod #TeamCulture #AgileCoaching #ProcessImprovement #ProvCraft #ContinuousImprovement

SOURCES

1. Daniel S. Vacanti, "When Will It Be Done? Lean-Agile Forecasting To Answer Your Customers' Most Important Question," Chapters 8–10
2. Businessmap, SCHLENK case study (chemical manufacturing, R&D workflow)