Most engineering leaders can tell you their squad is busy. Far fewer can tell you where work is actually getting stuck. A cumulative flow diagram gives you that visibility: it shows how work items accumulate across each stage of your delivery pipeline over time, making bottlenecks visible before they derail a sprint. This page covers what a cumulative flow diagram is, how to read and measure one, what good and concerning patterns look like, and how to act on what you find.
Key takeaways
- A cumulative flow diagram visualizes the total number of work items in each stage of your delivery process over a given time period, making it one of the clearest tools for spotting where flow breaks down across a squad's pipeline. Teams that review their CFD regularly can catch bottlenecks before they compound into missed commitments.
- To read a CFD, measure the vertical distance between two bands at any point in time to see work in progress for that stage, and measure the horizontal distance between when an item enters one band and exits another to approximate cycle time. No single published benchmark defines a "good" CFD shape, but a healthy chart shows bands of roughly consistent width and a steady upward slope in the "done" band.
- The most common mistake teams make with a cumulative flow diagram is treating a widening band as a capacity problem and adding more players, when the real issue is a process constraint upstream. Adding people to a clogged stage increases WIP and typically makes the bottleneck worse, not better.
- DevStats surfaces flow and throughput data automatically by connecting to your issue tracker, with benchmarks against 1,000+ engineering teams so you can see how your squad's delivery rate compares. Start a free trial to see your numbers in under two minutes.
Cumulative flow diagram definition
A cumulative flow diagram (CFD) is a stacked area chart that shows the total number of work items in each stage of a workflow, plotted over time. Each colored band represents one stage, such as backlog, in progress, in review, or done. The chart makes it immediately visible when work accumulates in a particular stage or when overall throughput slows.
Technically, a CFD is derived from your issue tracker data. The vertical gap between two adjacent bands at any given date equals the work in progress (WIP) for that stage. The horizontal gap between when an item crosses into one band and when it exits represents approximate cycle time. Teams that connect their issue cycle time data to a CFD get a far clearer picture of where time is being lost than sprint velocity alone provides. When delivery flow is healthy, stakeholders get more predictable release timelines and fewer last-minute surprises.
Why a cumulative flow diagram matters for engineering teams
Without a CFD, bottlenecks are invisible until they become emergencies. A squad might be hitting sprint commitments on paper while a review stage quietly accumulates a two-week backlog. By the time the slowdown shows up in velocity or missed deadlines, the root cause is already weeks old. The CFD surfaces that signal early, so you can act before the sprint is already lost.
For engineering leaders, the CFD connects directly to the KPIs that matter most: predictable delivery, sustainable WIP, and stakeholder confidence. A widening "in review" band, for example, is a signal to examine your code review process, not to add more players. The CFD also maps cleanly to the Flow framework and complements SPACE framework metrics by measuring the efficiency of processes rather than the output of individuals. Teams that track sprint health alongside their CFD get leading indicators of delivery risk, not just lagging confirmation of what already went wrong.
Measurement is the starting point. The engineering manager is the one who reads the pattern, applies context, and decides what to change.
How to measure a cumulative flow diagram
A CFD is generated from your issue tracker, such as Jira, Linear, or GitHub Issues. For each date in your chosen time range, you count the total number of items that have ever entered each workflow stage. Those counts are stacked to create the area bands. The key measurements you read from the chart are WIP (vertical band width at a point in time) and approximate cycle time (horizontal distance an item travels across bands). You can also read throughput from the slope of the "done" band: a steeper slope means more items completing per unit of time.
No single published benchmark defines an ideal CFD shape, because the right pattern depends on your team size, workflow stages, and release model. The table below describes qualitative signal levels. You can compare your flow patterns against peer teams using DevStats benchmarks.
| Performance level | CFD pattern | What it signals |
|---|---|---|
| Elite | Bands are narrow and consistent width; "done" slope is steep and steady | Low WIP, fast flow, predictable delivery cadence |
| High | Bands are mostly consistent with occasional short-lived widening | Generally healthy flow with manageable, recoverable bottlenecks |
| Medium | One or two bands noticeably wider than others; "done" slope flattens periodically | Recurring bottleneck in a specific stage; throughput is inconsistent |
| Low | A band grows continuously wider over weeks; "done" slope is flat or declining | Systemic WIP buildup; delivery is stalling and cycle time is expanding |
Benchmarks vary by team size, codebase complexity, and release model. Use the patterns above as directional signals, not hard thresholds.
Cumulative flow diagram in practice: a real example
A VP of Engineering at a 45-person SaaS company noticed her squad was consistently missing sprint goals despite high activity. She pulled a CFD covering the previous eight weeks and saw the "in review" band growing wider every sprint while the "done" band's slope was nearly flat. The data pointed to a specific process constraint: pull requests were sitting in review for four or more days before being merged. She didn't need more players. She needed a different review process.
She introduced a squad norm of same-day first review for any PR open longer than 24 hours and set a WIP limit of three items per player in the review stage. Over the following three sprints, she tracked the CFD alongside PR cycle time to confirm the band was narrowing. The "done" slope steepened, delivery became more predictable, and stakeholder confidence in the team's commitments improved. The CFD told her where to look. She decided what to do about it.
How to improve your cumulative flow diagram
- Set explicit WIP limits per stage. Identify the widest band in your CFD and cap the number of items allowed in that stage at any one time. WIP limits force the squad to finish work before pulling new items in, which narrows the band and accelerates flow. Watch for the bottleneck shifting to an adjacent stage after you impose the limit.
- Audit your workflow stages for accuracy. A CFD is only as useful as the data feeding it. If players aren't moving cards through stages consistently, bands will misrepresent actual flow. Run a one-sprint audit to confirm that stage transitions in your issue tracker reflect real work state changes.
- Pair the CFD with cycle time data. A widening band tells you where work is piling up. Issue cycle time tells you how long individual items are spending there. Using both together helps you distinguish between a surge in new work versus a slowdown in throughput for a specific stage.
- Review the CFD at the start of each sprint retrospective. Bring the last two to four weeks of CFD data into your retro. Ask the squad to name the widest band and propose one process change to address it. This keeps the conversation grounded in flow data rather than anecdote.
- Monitor allocation shifts alongside the CFD. If a band widens after a squad member moves to a different project, that's a capacity signal worth examining through allocation data. The CFD shows the symptom. Allocation data helps you identify whether resourcing decisions are the cause.
Cumulative flow diagram vs. burndown chart
Both charts track work over time, but they answer different questions: a cumulative flow diagram shows where work is accumulating across all stages simultaneously, while a burndown chart shows how much work remains against a target within a fixed sprint or release window.
| Cumulative flow diagram | Burndown chart | |
|---|---|---|
| Measures | Work item counts across all workflow stages over time | Remaining work against a sprint or release target |
| Starts when | Items enter any tracked workflow stage | Sprint or iteration begins |
| Ends when | Continuously updated; no fixed endpoint | Sprint or iteration ends |
| Best for | Identifying bottlenecks and flow efficiency across the full pipeline | Tracking progress toward a specific sprint commitment |
Use a burndown chart to manage a sprint in flight. Use a cumulative flow diagram to understand the systemic flow patterns that determine whether your squad can reliably hit those sprints in the first place.