Cumulative Flow Diagram: Reading Bottlenecks at a Glance

A cumulative flow diagram, or CFD, is a stacked area chart with time along the bottom and a count of work items up the side. Each colored band is one state of your workflow, such as To Do, In Progress or Done. The thickness of a band on any day is how many items were in that state; the top edge of the stack is everything that has arrived; the bottom band, Done, only ever grows. Read it by looking at the bands’ widths over time: bands that run parallel mean work is flowing, and a band that keeps getting thicker is where work is piling up, usually because the step after it is the bottleneck.

This piece is about reading the chart. For the four flow numbers behind it, see cycle time vs lead time. For the limit that keeps the bands thin, see kanban WIP limits.

What the bands mean

Microsoft’s documentation for the Azure DevOps cumulative flow diagram↗ (opens in a new tab) describes it as showing the count of items in each board column for a selected time period. The later states sit at the bottom of the stack and the earliest at the top. Kanban University’s guide says the same thing in its own words: the colored areas represent the number of work items within each activity, and how they move across all activities, top to bottom, until done.

• Band thickness on one day: how many items were in that state that day.
• Thickness of all the middle bands together: work in progress, everything started but not finished.
• Top edge of the whole stack: the total number of items that have ever entered the board. It rises when work arrives.
• Top edge of the Done band: the running total of finished items. Its slope is throughput.
• Horizontal distance between the line where items enter the first working state and the top of Done: roughly how long items take to get through, on average.

That last reading is approximate. Microsoft’s own cumulative flow guidance↗ (opens in a new tab) notes that its CFD charts do not give discrete lead time and cycle time values; separate widgets do. Use the horizontal gap to notice that items are taking longer, and a proper cycle time calculation to say how much longer.

Spotting work in progress growing

The most useful thing a CFD shows is WIP growth, because it is easy to miss on the board itself. Any single day looks normal. Over three weeks, the middle bands fatten while the Done band’s slope stays flat: the team is starting work faster than it finishes it. Microsoft’s guidance puts it plainly: more WIP leads to longer cycle and lead times, and a large amount of WIP usually shows up as a vertical bulge that expands into an oval the longer it lasts.

The fix is rarely more effort. It is a lower limit on what may be started, and help for whichever step is slowest.

Reading bottlenecks at a glance

Atlassian’s Jira documentation↗ (opens in a new tab) gives the one rule worth memorizing: if an area is widening vertically over time, the column it equates to will generally be a bottleneck. Microsoft adds a refinement worth knowing: a bulge in one state often means the step after it is having the problem. Work piles up in development when testing is slow, not because development is.

• One band widening, the rest steady: a bottleneck at or just after that state. Look at the next step first.
• Every band flat for days: nobody is updating the board, or work across the whole system has stopped. Microsoft lists both as causes of flat lines.
• Stair steps instead of slopes: cards are moved in batches, for example once a week. The chart reflects the updating habit, not the work.
• Top edge rising steeply while Done is flat: arrivals are outrunning finishing. The backlog is growing, even if the team feels busy.
• Top edge flat, Done catching up: nothing new is arriving. Good for a release push; worrying if it lasts.
• Done rising while the top edge rises at the same slope and the middle stays thin: the healthy picture. Work arrives and leaves at about the same rate.

What a CFD does not show

• Which item is stuck. A band tells you a state is crowded, not which card is old. Work item age answers that.
• Size. Ten small items and ten large ones draw the same band.
• Items that go backward. A card moved from testing back to development thins one band and thickens another, which can look like progress.
• Scope swaps. Microsoft notes that if the same number of items is added and removed on the same day, the top line stays flat and the change is invisible.
• Anything the board does not record. Work done off the board never reaches the chart.

A worked example

Here are daily counts for a small team’s four-lane board over two weeks. Done is the running total of everything finished since the start.

day   to_do  next_up  in_progress  done
1       14      4         3          0
2       15      4         3          2
3       15      4         4          3
4       16      4         5          3
5       17      3         6          4
8       18      4         7          4
9       18      4         8          5
10      19      3         9          5
11      19      4         8          7
12      18      3         6         10

Stacked, days 1 to 10 show the In Progress band tripling from 3 to 9 while Done creeps from 0 to 5: WIP growth, with arrivals still coming in at the top. On day 10 the team agreed a limit of 6 and stopped starting; by day 12 In Progress is back to 6 and Done jumped by five in two days. The chart shows both the problem and the effect of the fix, which is its best use.

Building a cumulative flow diagram by hand

You do not need a reporting tool. You need one number per state per day, taken at the same time each day, and any spreadsheet:

1. Make one column per state, earliest on the left, plus a date column.
2. Every day, at the same time, record how many items are in each state. For Done, record the running total of items ever finished, not what is currently visible, so the band never shrinks.
3. Select the state columns with Done first and choose a stacked area chart, so Done sits at the bottom.
4. Look at it once a week, not every day. Trends take a week or two to show.
5. Mark the dates you changed a limit or a policy on the chart, so you can see whether the change worked.

A continuous board suits a rolling window, such as the last 30 or 60 days. If you work in iterations, Microsoft’s guidance describes a fixed-period version where the top line is the scope for the sprint and changes to it show scope added or removed; read that way, it works like a burndown chart turned upside down.

A manual CFD for a fenbs board

fenbs does not draw a cumulative flow diagram, or any flow chart. The Insights panel above the board shows current counts, open, urgent P1, In Progress and Completed, and each lane shows its count beside its name. History records every move with who made it and how long ago. That is enough for the daily count above, as long as someone takes it:

• Copy the four lane counts, To Do, Next Up, In Progress and Completed, into a spreadsheet at the same time each day.
• Or ask a connected AI assistant to do it: fenbs_list_items filters by lane, using the keys backlog, next, doing and done.
• If the board archives closed tasks after a set time (a board setting whose default is never), the Completed count drops as tasks leave. Keep your own running total of tasks moved into Completed instead.
• Insights counts only tasks that were actually built in its Completed figure, not ones closed as duplicates or won’t fix. Decide which count your chart uses and keep it.

Count the tasks in each lane on the board: backlog, next, doing, done.
Append one line to cfd.csv: today's date (YYYY-MM-DD), then the four counts.
Do not move or change any task.