Cumulative Flow Diagrams (CFDs)

Numbers in a spreadsheet don't reveal flow problems. A cumulative flow diagram makes WIP buildup, bottlenecks, and throughput trends visible at a glance.

Overview

A cumulative flow diagram is a stacked area chart of your workflow. Each band is a state — Backlog, In Development, In Review, Done — and each vertical slice counts how many items sit in each state on that day. That’s the whole trick, and it’s enough: arrival rate, throughput, WIP, lead time, and cycle time are all readable straight off the geometry, no per-ticket tracking required.

The tool below lets you define states, enter period snapshots, and calculate flow metrics over any range using Little’s Law. For the full metric vocabulary, start with the Flow Metrics Guide.

How to Read a CFD

The chart has a grammar. Four rules cover it:

• A band’s width is WIP. The vertical thickness of a band is the number of items in that state.
• A band’s slope is rate. A band’s top edge rises as work arrives; its bottom edge rises as work departs. Matching slopes mean the state has the same arrival and departure rate.
• Vertical gap is WIP between states. The distance between any two band boundaries is the total work in progress between them.
• Horizontal gap is time. The left-to-right distance between two boundaries approximates how long an item takes to travel between those states.

Little’s Law ties the grammar together: lead time equals WIP divided by throughput. Fat bands mean long waits — the arithmetic allows no other outcome. It’s also why cutting WIP, not adding people, is usually the fastest way to shorten cycle time.

The Pattern Gallery

Once you know the grammar, dysfunction has a shape. Each pattern below links to a preset in the tool — open it and look for what’s named.

Parallel, evenly spaced bands: healthy flow. Open Healthy Flow. The queues hold one or two items for fourteen straight days and Done climbs in a straight line. A healthy CFD is boring. Boring is the goal.

A widening middle band: bottleneck. Open Review Bottleneck and watch Ready for Review fatten from 2 items to 17 while Done crawls from 1 to 5. Development looks on track the entire time. The customer sees almost nothing ship.

One band swallowing the chart: too much started. Open Multitasking in Dev. In Development swells from 4 items to 26, and Done adds a single item in two weeks. Everyone is busy. Nothing finishes.

Thin, ragged bands under a flat top line: starved intake. Open Starving Pipeline. The backlog runs dry and the bands sputter. The constraint here isn’t the team — it’s whatever feeds the team.

Stair-steps: batchy handoffs. Open Big Batch Handoffs. Queues spike and drain in cascading waves, and Done stays flat for fourteen days before leaping. Work is moving in lumps, not flowing.

A Worked Example

Load Fast Cycle Time and do the arithmetic yourself. Eleven items reach Done in eleven days: throughput is one per day. On any given day about 5.5 items sit in active work between In Development and Done. Little’s Law: 5.5 ÷ 1 = 5.5 days of cycle time — exactly what the Cycle Time card reads. Two numbers off the chart, no stopwatch.

Now break something. Load Multitasking in Dev again and check the Cycle Time card: roughly 259 days. Not because any item takes a year — because twenty-plus items in flight divided by a throughput of one item every thirteen days is a system that has nearly stopped. In the last four periods, cap In Development at 5 and add the overflow to Done, modeling a team that stops starting and starts finishing. Cycle time collapses to about 8.5 days. Same people, same skill, less WIP. That’s Flow as arithmetic instead of aspiration.

When we run this with a team, we don’t start from a blank chart — we pull column counts from their real board, one snapshot per week, and enter a quarter’s history. Then we ask which gallery pattern they’re looking at. The chart never starts the argument about why; it just ends the argument about whether.

Two traps. A cumulative line can never go down — if yours does, items were deleted or dragged backward, and you have a data problem before you have a process problem. And Little’s Law gives system averages, not promises: 5.5 days is what the pipeline does on average, not a delivery date for the ticket your VP is asking about.

A CFD won’t tell you why reviews pile up. It makes the pile impossible to unsee — and once a team has seen it, “we’re all busy” stops working as an answer.