Cumulative flow diagram

Goal

The cumulative flow diagram is the chart of a workflow's history: it shows where work piles up and how long it takes to get through. A kanban board or a task board shows the state of work on a given day. The diagram lines these snapshots up day after day: each column becomes a band, each day a point on the time axis.

From it, the team reads which state needs more capacity, where to set or tighten a WIP limit and what lead time to quote to a requester. The deliverable is the diagram kept up to date and a record of the metrics over a window of a few weeks: average work in progress, throughput, lead time and cycle time, checked against Little's law.

Burndown and burn-up charts compare the progress of a sprint or a release with a committed scope and a deadline: will the team finish what it promised? The cumulative flow diagram plots a continuous flow over any window, independent of sprints. It shows where the work is waiting.

Usage

When to use it

• Continuous flow without a fixed iteration: application support, change requests, case processing.
• Complaints about lead times with no named cause: the widening band points to the state that holds the work back.
• Setting a WIP limit: Little's law puts a number on the expected effect; the diagram shows the actual effect.
• A lead time to quote to a requester or to write into a service level agreement (SLA): the measured lead time, taken at a percentile, replaces the estimate.
• A Scrum team whose items stall during the sprint: the diagram can also be drawn on the columns of the sprint board.
• A tracking tool that dates every state change: the history already exists; it only needs to be accumulated.

When not to use it

• A single delivery with a fixed deadline: the question becomes "will we finish on time?", so use a burn-up chart.
• Fewer than about ten items delivered per month: the curves shrink to a few steps; track the age of each item on the board instead.

Description

Curves and bands

The horizontal axis shows time, in working or calendar days. The vertical axis shows a cumulative count of items. Each state has its curve: for each day, it counts the items that have reached that state, whether they are still there or have moved further. Items delivered before the window are not counted. A cumulative curve therefore never goes down, except when an item is withdrawn or sent back.

The curves stack in the order of the board. The Done curve forms the bottom of the chart. The upstream states pile up above it, and the top curve counts the committed items. The space between two neighbouring curves is the band of a state.

Three boundaries divide the flow. The commitment point is the moment the team commits to delivering an item: the item leaves the list of requests and enters the system. The start of work is the entry into the first state where someone works on the item. Delivery is the entry into Done. Uncommitted requests stay off the diagram. Their list grows and shrinks as priorities are traded off, and its band would be so tall that the other bands flatten on the vertical scale.

The flow metrics

On the diagram, work in progress is the vertical gap between the commitment curve and the Done curve. Throughput is the slope of the Done curve. Lead time is the horizontal gap between the same curves, and cycle time the horizontal gap between the start-of-work curve and the Done curve. When items leave in the order they entered, the horizontal gap gives the lead time of the item at the height where the gap is measured. Otherwise it approximates the average lead time.

Names vary between authors and between tools. Some tools call the interval between commitment and delivery the cycle time. In the lean tradition, to which Value Stream Mapping belongs, cycle time means the working time at a single step. Other teams measure lead time from the request rather than from the commitment. The team fixes its boundaries on the board and writes its definition at the top of the record. A lead time can be compared with another only when both state their two boundaries.

Little's law

John D. C. Little proved a queueing relation, L = λW: the average number of items in a system equals their average arrival rate multiplied by the average time they spend in it.

The law concerns averages and a stable system: over the observed window, arrivals roughly equal departures, work in progress ends at the level where it started and every committed item leaves, delivered or withdrawn. The departure rate then replaces the arrival rate λ. In flow terms:

Average work in progress = Average throughput × Average lead time, hence Average lead time = Average work in progress ÷ Average throughput.

The law holds between any two boundaries, provided work in progress is counted between the same boundaries. The number of items between the start of work and delivery, divided by throughput, gives the average cycle time. The number of items waiting before the start of work, divided by throughput, gives the average wait. Lead time breaks down into wait plus cycle time, both read on the same diagram. In the example below, over the stable weeks, 8 items are in development or in review and 4 wait in Ready, for a throughput of 6 per week. The average cycle time is 8 ÷ 6, about 1.3 weeks, and the wait 4 ÷ 6, about 0.7 weeks: a third of the 2 weeks of lead time passes before anyone touches the item.

To set a WIP limit from this relation, see Kanban board and WIP limits.

Setting up the diagram

1. Name the states and set the boundaries. The team takes the columns of its board and marks the commitment point, the start of work and delivery. Each state gets a written entry rule. Without one, two people classify the same item differently.
2. Choose what to count. A diagram counts items and ignores their size. The team therefore puts items of comparable size on one diagram. Incidents and change requests each get their own diagram.
3. Record the transition dates. For each item, the tracking tool records the date it entered each state. Without a tool, the team counts the cards in each column every day at the same time.
4. Choose the window. It covers several lead times: an average computed over less than one lead time contains only the fast items.
5. Plot. For each day and each state, the team counts the items that have entered that state or a later one. It stacks the curves with Done at the bottom and resets the Done count to zero on the first day of the window.
6. Read and calculate. The team spots the patterns and records average work in progress, throughput, lead time and cycle time. It divides average work in progress by throughput and compares the result with the average lead time measured item by item. A gap signals an unstable flow or wrong data: items closed without passing through the states, backward moves nobody recorded.
7. Act, then read again. After a new WIP limit, the items already committed leave with the lead time they have accumulated. The measured lead time falls only after a period equal to the old lead time, two weeks in the example. The team waits at least that long before judging the change.

Reading the patterns

Bands of constant thickness describe a stable flow: each state passes on as much as it receives. A widening band describes a state that receives more than it passes on, the bottleneck. The band below it thins, because the downstream state runs short of work. The rule holds for a state where people work. On a waiting state, such as a "Ready for review" column, the widening band points to the bottleneck in the next state, which no longer pulls work.

A flat Done curve signals that nothing leaves: a blockage, a release freeze, holidays. A stair-step Done curve signals batch deliveries, and the lead time of each item includes the wait for the batch. A commitment curve that rises faster than the Done curve signals a team that commits to more than it delivers: work in progress and lead time grow together. A curve that goes down signals a withdrawal or a backward move, and the team checks its data before drawing conclusions.

What distorts the reading

An average hides the blocked item. A card that has not moved for three weeks barely shifts a band. The age of each open item, tracked on the board, exposes it on the day it exceeds the usual lead time.

Dates entered after the fact shift the curves. A card moved on Friday for work finished on Tuesday counts the item in Done three days late. When the whole team updates the board on Friday, the diagram shows batches that never existed. The average lead time varies little; the lead time of each item is wrong. The sign is a stair-step Done curve whose every step falls on the day the team updates the board, while releases follow another rhythm.

Backward moves blur the curves. A review sends an item from the In review column back to Development. The team decides whether the item stays counted in the furthest state it reached or moves back down, and it applies the same rule to every record.

The diagram does not forecast a completion date. Extending the Done curve to a fixed scope amounts to drawing a burn-up chart. A lead-time commitment to a requester rests on the distribution of measured lead times. The team sorts the lead times of the delivered items and takes the value below which 85% of them fall: "85% of requests delivered in 12 days or less". The average, about 8 days in the scatterplot below, fails as a commitment: more than a third of requests take longer.

Throughput set as a target gets gamed. A team judged on its throughput splits its items into smaller ones. Throughput rises, and the requester is not served any sooner. Two teams compared by throughput are compared by how they split their work.

AI considerations

A language model writes the script or the spreadsheet formulas that turn a history export, with identifier, state and transition date, into cumulative counts per day and per state, then into a diagram. The analyst checks the result. She takes one day and counts its items by hand in the export. Over a stable window, she divides average work in progress by throughput and must arrive at the average lead time computed item by item.

The model can also describe a diagram: it names the widening band and the week the Done curve flattens. It cannot identify the cause. An absent reviewer, an unavailable test environment and a release freeze draw the same band. The team finds the cause in a retrospective.

A tracking tool's export carries the titles and descriptions of the requests, sometimes with the names of clients or insured persons. The calculation needs the identifier, type, state and dates. The rest does not go to a service whose terms of use the organisation does not control.

Examples

The application team of a pension fund processes change requests over four weeks, with a single reviewer. It records the states every day. The table shows the Fridays, starting from the initial state on the Friday before week 1.

In weeks 1 and 2, the flow is stable: 12 items committed, 6 delivered per week, an average lead time of 2 weeks. The diagram confirms it: the commitment curve reaches 12 on the Friday of W0, the Done curve on the Friday of W2, ten working days later. In week 3, the reviewer is absent for two days. The In review band widens, throughput drops to 3 and work in progress rises to 15. Weeks 3 and 4 are unstable: the diagram shows the degradation; Little's law gives only a projection. If throughput returns to 6 per week, work in progress of 15 points to 2.5 weeks of lead time. On the Monday of W4, the team limits Development to 3 items and In review to 4, and two developers move to reviewing.

On the Friday of W4, work in progress stands at 7: if throughput returns to 6, the projected lead time is 7 ÷ 6, a little over a week. The 24th item delivered that day had been committed on the Friday of W2: ten days. It went through the bottleneck. The measured lead time will fall only once the items committed before the limits have left.

Visualisations

Each state keeps its colour from one snapshot to the next, and the vertical axis starts at zero on the first day of the window. The annotations point to what the reader must see: a vertical gap labelled work in progress, a horizontal gap labelled lead time, the widening band named.

The lead time scatterplot plots each delivered item by its delivery date and its lead time, with the 50th and 85th percentile lines: it shows the items that the diagram's averages hide. The lead time histogram gives the distribution on which a lead-time commitment rests.

Cost

Tools

Tracking tools draw the diagram from their history: Jira in its board reports, Azure DevOps in a widget, Businessmap (formerly Kanbanize) in its analytics. They fit as soon as the team runs its board in them. Before the first reading, the team checks in their documentation how they define lead time and cycle time.

Extensions such as ActionableAgile Analytics add the lead time scatterplot, percentiles and the age of open items.

A spreadsheet is enough for a team without a tool or to check a tool: one row per item with its transition dates, a pivot table counting per day and per state, a stacked area chart. A Python script with pandas and matplotlib does the same job on an export and can be kept under version control.

Sources

• David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business, Blue Hole Press, 2010: the cumulative flow diagram and lead time as management metrics of a kanban system.
• Donald G. Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development, Celeritas Publishing, 2009, principles Q11 The Cumulative Flow Principle and Q12 Little's Formula: the cumulative arrival and departure curves, the vertical gap as a queue, the horizontal gap as a waiting time, then Little's formula.
• Wolfram MathWorld, "Little's Law": the statement L = λW and its attribution to John D. C. Little.