Cumulative Flow Diagram

Put a kanban board on the wall and anyone can see how many cards are in each column right now. A kanban board represents one piece of work as one card and lines those cards up in columns by state. The catch is that the board only shows today. Whether that card was sitting in the same column three days ago, or whether the waiting-for-review column was this crowded last month, is nowhere on it.

So the conversation ran on impressions. Someone would say releases felt slower lately, someone else would blame the review queue, and a third person would say it had always been like that. None of the three had evidence, so the meeting moved on to the next item without a conclusion.

A cumulative flow diagram is what you get by photographing the board every day and stacking the photos. It puts today's board and last month's board on the same screen, which turns "it feels slower" into "the waiting-for-review column went from 4 cards to 19 over three weeks." It takes the kanban premise — make the work visible — and stretches it along a time axis.

One horizontal axis, one vertical axis, and one band for every column on the board.

1. The horizontal axis is the date. One point per day, usually covering the last month or two.
2. The vertical axis is a count of cards. Every card that has reached a given state is counted cumulatively, which is why no line on this chart ever comes back down.
3. Each band maps to one column. Five columns — queued, in development, code review, waiting for release, done — give you five bands. Done goes on the bottom and the rest stack upward from there, so the topmost line is every request that has ever arrived.

Once it's drawn, the shape of the chart tells you three things.

1. The thickness of a band is how many cards are sitting in that column. If the in-development band swells from 3 cards to 11, more work is entering than leaving, and that column is the bottleneck — the slowest stage, which sets the pace for everything behind it.
2. The horizontal distance between two lines is how long one card takes to cross that stretch. Measure from the top line to the bottom line and you get lead time, the span from request to delivery. Measure from the line where development starts and you get cycle time. A lead time of 9 days against a cycle time of 2 means seven of those days were spent in a queue.
3. The slope of the bottom band is throughput, the number of items finished in a period. A week where the slope flattens is a week where little shipped.

The healthy shape is bands of roughly steady thickness all climbing together. Think of a reservoir that drains as fast as it fills: the water level only rises in the stage where inflow outruns outflow.

In most teams the chart is drawn by the issue tracker rather than by a person. The tool already records every time a card changes column, so it's a menu item rather than a spreadsheet exercise. What people have to do is threefold.

1. Make the columns match the real flow. A waiting stage that isn't a column can't show up on the chart. If three days of waiting for release hide inside the in-development column, the chart will say development is slow.
2. Decide how often to look. Checking daily means reacting to daily noise, so most teams open it once every two weeks at the retrospective.
3. Mark changes on the chart. Note the day the work-in-progress limit (WIP limit) dropped from five to three — the cap on how many cards a column may hold at once — and you can see whether the band thinned out afterward.

There are three audiences. The first is the team itself, checking which column is short on hands. The second is a team lead or product manager deciding where to put people next week and whether a new request can be taken on now. The third is anyone outside the team, and that reading needs an interpreter. A top line climbing steeply looks like a team shipping hard, when it may only mean requests are piling up.

"Looking at the diagram, the waiting-for-release band has been thickening for three weeks."

A claim that release is the bottleneck. It usually leads to lowering the cap on the column in front of it, or putting another person on releases.

"The arrival line got steeper but the done line is flat."

More requests are coming in while the same amount leaves, so the queue is growing and lead time is stretching.

"There's not enough here for a diagram — let's just walk the cards one by one."

With only a handful of cards the chart comes out as a staircase. A team that finishes two or three items a week never gets bands smooth enough to read.

At Pagedeck this chart opens the retrospective every two weeks. One month the code review band kept thickening, which is how the team discovered Theo had been doing every review alone. Development had not slowed at all, but lead time had gone from 6 days to 11, and all five added days were spent waiting for a review.

The team added a second reviewer and dropped the in-development cap by one. Three weeks later, when the code review band thinned again, Mia noted the date of the change on the chart itself.

The most common mistake is expecting the lines to go down. Anyone who met the burndown chart first reads it that way, since a burndown draws remaining work falling toward zero. But every line here is a cumulative count and by definition cannot fall. What matters is not the height but the thickness of the bands and the gap between the lines. Read a rising chart as bad news and you end up concluding that a perfectly healthy team is falling behind.

Reading a thick band as a sign of hard work goes wrong the same way. A column full of cards looks busy, so the assumption is natural. What it actually means is that many things are open at once, and the more things are open at once, the longer any single one takes to finish. Treat that as an achievement and the team starts opening more cards — six months on, twenty items are in progress and three are done.