Cumulative Flow Diagram
A stacked area chart showing how work items accumulate in each workflow state over time, revealing bottlenecks, flow stability, and work-in-progress trends.
What it is
A Cumulative Flow Diagram (CFD) is a stacked area chart that shows how work items accumulate in each workflow state over time. It is one of the most powerful diagnostic tools in Kanban.
- Horizontal axis = time. Usually days or weeks.
- Vertical axis = cumulative items. The total number of items that have entered each stage since tracking began.
- Each band = workflow stage. "To Do," "In Progress," "In Review," "Done."
- Width of band = WIP in that stage. A widening band means work is accumulating there.
- Healthy CFD shows smooth, roughly parallel lines. This indicates stable WIP and predictable flow.
The top line shows total work entered. The bottom line of the "Done" band shows total work completed. The vertical distance between any two lines is the WIP in that stage.
When to use it
Review the CFD weekly, either in standups or retrospectives. It takes 30 seconds to scan and reveals more about flow health than a full status report.
Use it to spot trends before they become crises. A band that has been widening for two weeks is a bottleneck forming in real time.
Key concepts
Bands
Each coloured band represents a workflow stage. The area of the band shows how many items were in that stage at each point in time.
Widening / Narrowing
A band that gets wider over time means work is entering that stage faster than it is leaving. A narrowing band means the stage is draining.
Flat Lines
A flat top line means no new work is entering the system. A flat boundary between two bands means no work is moving between those stages. Both are signals to investigate.
Approximate Lead Time
The horizontal distance between the "To Do" entry line and the "Done" completion line at any vertical point gives a rough visual indication of lead time.
Do not expect perfectly parallel lines. Some variation is normal. What matters is the trend: are the bands stable over weeks, or is one consistently widening?
Worked Example: Reading a Real CFD
Scenario: A 6-person team has been tracking their CFD for 4 weeks. Their workflow has 4 stages: "To Do," "In Progress," "In Review," "Done."
- Week 1: All bands are narrow and roughly parallel. 5 items per week flowing through smoothly.
- Week 2: The "In Review" band starts widening. Items are moving slowly through code review.
- Week 3: "In Review" band is now 40% wider than "In Progress." A clear bottleneck.
- Week 4: Team investigates. Discovery: one senior developer is the only code reviewer, and they are away 2 days per week. Solution: train a second reviewer.
Without the CFD, the team would have felt busy (coding new features) but not realised their real constraint was code review capacity. The CFD made it visible in 2 weeks instead of learning about it from frustrated POs a month later.
Step-by-Step: Interpreting a CFD
- Look at the overall shape. Do lines run parallel (healthy) or is one band widening (bottleneck)?
- Scan the vertical distance between lines. A large gap between "In Progress" and "In Review" means items are piling up waiting to be reviewed.
- Check the slopes. A steep slope means work is moving fast through that stage. A flat slope means work is stuck.
- Look for trends over 2+ weeks. One bad day is noise; a band widening for 2 weeks is a signal.
- Identify which band is the bottleneck. The widest band is where your constraint lives. That's where to focus improvement effort.
Metrics Extracted from a CFD
Work In Progress (WIP): The vertical distance between any two lines at a given time shows how many items are currently in that stage. If "In Progress" shows 15 items when WIP limit is 10, you are overloaded.
Throughput: How fast is the top line moving up? A steep slope means you are completing lots of work. A flat slope means nothing is reaching "Done."
Lead Time: The horizontal distance from entry to completion. A wide CFD (left to right) means long lead times. A narrow CFD means quick delivery.
Cycle Time per Stage: How long does an item spend in "In Progress" vs "In Review"? Draw a vertical line at a point and measure the width of each band. If "In Review" is much wider, that stage is slow.
Team Problems a CFD Reveals
- Review bottleneck: "In Review" band widens while "In Progress" drains. Not enough reviewers, or review is too slow.
- Testing backlog: "In Test" band widens. QA is understaffed, test environment is unstable, or tests are too slow.
- Too much WIP: All bands are very wide. Team is starting too much work before finishing what's in progress. Solution: lower WIP limits.
- Blocked work: One band widens suddenly then flattens. A blocker (missing dependencies, tool outage, stakeholder approval) is holding items hostage.
- Uneven distribution: Some bands are narrow and fast; others are wide and slow. Team is not balanced across stages.
CFD vs Burndown Chart
Burndown: Shows how many items are left (one line going down). Good for sprints; hides flow problems.
CFD: Shows how items move through stages (multiple bands). Good for continuous flow; reveals bottlenecks. A CFD shows *where* work is getting stuck; a burndown just shows *how much* is left.
Common pitfalls
| Pitfall | Why it hurts | What to do instead |
|---|---|---|
| Only looking when things go wrong | Misses gradual degradation of flow. | Review the CFD every week as a habit. |
| Not understanding band meanings | Misdiagnoses which stage is the problem. | Label bands clearly and ensure the team knows what each colour represents. |
| Comparing across teams | Different workflows produce different shapes. | Use CFDs for internal trend analysis only. |
| Ignoring the diagram | The team flies blind to flow problems. | Make the CFD visible on a dashboard or wall. |
| Failing to act on patterns | Data without action is waste. | When a band widens for two weeks, discuss it in the retrospective and run an experiment. |
NZ context
Cumulative Flow Diagrams are built into the tools most New Zealand teams already use: Jira, Azure DevOps, and GitHub Projects. Despite this, many teams never look at them.
Set a recurring calendar reminder to review the CFD before standup. In five minutes you can confirm flow is healthy, or identify a column that needs the team's attention that day.
Career level guidance
Senior: Learn to read a CFD at a glance. Be the person in the retrospective who can say, "The 'In Review' band has widened 30% over the last three sprints. That's our bottleneck." Bring the CFD to planning meetings to justify WIP limit adjustments.
Test Lead: Monitor the "In Test" band specifically. If it widens while "In Progress" narrows, the test stage is absorbing pressure. Use the CFD to demonstrate testing capacity constraints to leadership with objective data rather than anecdote.
Industry Reality
- Most teams have a CFD available in Jira or Azure DevOps but never open it. The tool is set up during project kick-off, auto-generates data, and then sits ignored for months until a delivery manager asks why velocity has tanked.
- Senior practitioners rarely print or export the CFD — they glance at it in the tool for 30 seconds before standup, note which band is behaving oddly, and bring one sentence of observation to the team. The textbook goal of "quantifying lead time from a CFD" is rarely done outside high-maturity shops.
- In NZ agencies and consultancies, the CFD is most commonly introduced by a Scrum Master or Delivery Lead who has worked with Kanban previously. Teams that run pure Scrum often skip it entirely, defaulting to the sprint burndown even when running a continuous flow.
- When a band widens, the honest organisational response is usually "we know, we're understaffed" rather than a structured experiment. Practitioners who get value from CFDs are those who use them to make the capacity argument visible and defensible to management — data beats anecdote.
- It is common for teams to track too many workflow stages (8–10 columns) in Jira, making the CFD unreadable. Effective practitioners push back on column proliferation and keep the board to 4–6 stages so the CFD bands remain interpretable.
Context guide
How the right level of Cumulative Flow Diagram effort changes based on team context.
| Context | Priority | Why |
|---|---|---|
| Government service delivery teams (Benefits NZ, CoverNZ, TransitNZ) running continuous-flow Kanban boards | Essential | Benefit and entitlement systems carry high consequence; a testing bottleneck caught at week 2 on the CFD prevents the kind of backlog that causes Privacy Act 2020 exposure or service outages affecting vulnerable citizens. |
| Fintech and banking teams at Harbour Bank or Pacific Bank managing regulatory release cadences | Essential | Compliance releases have hard external deadlines set by the Reserve Bank of NZ. The CFD surfaces whether throughput is on track weeks before the release window, allowing remediation rather than crisis. |
| Cross-functional product teams at TeleNZ or Pacific Air with mixed Scrum/Kanban workflows | High | Hybrid workflows often obscure which stage owns the delay. A CFD spanning sprint and continuous flow work makes the structural bottleneck visible rather than hidden inside sprint velocity numbers. |
| Small NZ startups or agencies with 3–4 person teams running short Scrum sprints | Medium | The CFD adds value but bandwidth is limited. Set it up in Jira once and review fortnightly at retrospectives; daily scrutiny is overkill when the team can see the whole board at a glance. |
| One-off fixed-scope projects lasting fewer than four weeks (e.g. LandNZ data migration sprints) | Low | Insufficient data accumulates for trend analysis in under four weeks. A simple task board and daily standup give faster feedback than a CFD whose bands have not yet developed meaningful shape. |
| Teams with highly variable work item sizes (mix of one-hour hotfixes and six-week epics) | Low | CFD bands count items, not effort — a widening "In Progress" band could mean ten trivial cards or one enormous feature stalled for a week. Use a cycle time scatter plot instead to surface outliers by actual duration. |
Trade-offs
What you gain and what you give up when you adopt Cumulative Flow Diagram.
| Advantage | Disadvantage | Use instead when… |
|---|---|---|
| Makes bottlenecks visible before they become delivery crises — a widening band at week 2 is recoverable; the same discovery at week 8 is not. | Requires consistent workflow stage definitions and disciplined ticket state transitions; teams that move cards irregularly or maintain 8+ columns produce unreadable charts. | The team's board has more than six columns or staff routinely skip stages — collapse the board first, then introduce the CFD once states are stable. |
| Provides an objective, data-driven argument for resourcing or WIP limit changes — far harder for leadership to dismiss than anecdotal "testing feels slow." | Treats all work items as equal units regardless of size or complexity, so band width reflects item count rather than actual effort invested — misleading when stories range from trivial to month-long. | Item sizes are highly variable — use a cycle time scatter plot instead, which shows actual duration per item and makes size-based outliers immediately visible. |
| Automatically generated in Jira, Azure DevOps, and GitHub Projects with zero manual data collection — the data exists from day one if the team uses a board at all. | Requires at least three to four weeks of data before trend lines become meaningful — on short projects or during team ramp-up, the chart provides false confidence through apparent stability caused by low data volume. | The project is under four weeks or the team is brand-new — use daily standups and a simple task board until enough data exists for the CFD to show genuine trends. |
| Works equally well for Scrum teams and Kanban teams — reveals intra-sprint bottlenecks that the burndown chart hides entirely. | Passive tool — the chart updates automatically, creating an illusion that someone is watching it when nobody is. Teams often discover it only when a crisis forces them to investigate retrospectively. | Nobody on the team has been assigned to review the CFD on a cadence — add a standing weekly calendar check before committing to the tool, or the data will accumulate unseen. |
Enterprise reality
How CFD monitoring changes at 200–300-developer scale across NZ banks, government agencies, and telcos
- CFD generation and alerting is automated via platform engineering pipelines — at Harbour Bank, delivery squads receive a weekly Confluence digest that includes auto-captured CFD snapshots and flags any band that has widened more than 20% week-on-week, so no one needs to manually open Jira; threshold breaches trigger a Slack notification to the squad lead and their delivery manager automatically.
- NZISM and PCI DSS compliance obligations mean that at banks and HealthNZ, flow data is treated as audit evidence — if your "In Test" band was wide in the week before a production release, the security team may ask why regression coverage was still incomplete; CFD screenshots become artefacts attached to change advisory board (CAB) submissions, not just internal team charts.
- Enterprise tooling handles volume through Azure DevOps Analytics or Jira Advanced Roadmaps with cross-programme CFDs — TeleNZ and TechServNZ run portfolio-level views that aggregate flow across 10–15 squads simultaneously, surfacing which stream owns the bottleneck across a programme of work rather than isolating it to a single board.
- At scale, CFD misreads cost real money: when squads in a multi-timezone Revenue NZ programme (Wellington + Auckland + offshore contractors) each maintain separate Jira projects with incompatible workflow stage names, portfolio CFDs show phantom bottlenecks caused by naming inconsistency rather than real flow problems — standardising workflow taxonomy across all squads is a precondition for trustworthy enterprise flow analytics, and failure to do so has caused Revenue NZ-style programmes to misallocate QA resource toward stages that appeared congested but were simply named differently.
◆ What I would do
Professional judgment — when to adopt Cumulative Flow Diagram, when to adapt it, and what to watch for.
The bottom line: A CFD is only useful if someone opens it on a fixed cadence — commit to a weekly review slot before the tool goes live, or four months of honest flow data will accumulate unseen while the team navigates by gut feel and burndown charts that hide where the real constraint lives.
Best Practices
- ✓ Review the CFD on a fixed cadence — weekly at minimum — not just when something feels wrong. Gradual band widening is invisible without regular comparison.
- ✓ Keep your workflow to 4–6 stages. More bands makes the chart cluttered and the signal hard to extract; collapse low-value waiting states into adjacent columns.
- ✓ Set WIP limits before interpreting the CFD. Without limits, a widening "In Progress" band is unsurprising — you put it there. WIP limits turn the CFD into an early-warning system.
- ✓ Annotate the CFD with events: team member out, major release, environment outage, scope change. Future you (and leadership) will need context for any unusual shapes.
- ✓ Use the CFD alongside cycle time scatter plots, not in isolation. The CFD shows where work accumulates; the scatter plot shows how long individual items take. Together they diagnose both capacity and predictability problems.
- ✓ When a band widens for two consecutive weeks, name it explicitly in the retrospective and propose one experiment — do not wait for it to become a crisis.
- ✓ As a tester, specifically track the "In Test" band relative to "In Dev." If dev throughput consistently outpaces test throughput, document the ratio and use it to build the case for additional test resource or shift-left automation.
- ✓ Avoid comparing CFDs across teams. Workflow definitions, team size, and item granularity all differ — the shape is only meaningful as an internal trend for one team over time.
Common Misconceptions
❌ Myth: A flat or slow-rising "Done" line means the team is underperforming.
Reality: A flat "Done" line may mean the team is completing large, high-value items that take longer to finish — or that work is blocked upstream, not that individuals are slow. The CFD diagnoses system constraints, not individual performance. Blaming people based on CFD shape without understanding the underlying workflow is a misuse of the tool.
❌ Myth: Parallel, smooth lines mean the team is working perfectly and needs no improvement.
Reality: Parallel lines mean flow is stable — but stable flow at a slow throughput rate is still slow. A CFD with narrow, parallel bands and a shallow slope indicates low throughput. Use the CFD alongside throughput and lead time metrics to assess whether the stable flow is actually fast enough to meet delivery commitments.
❌ Myth: The CFD only applies to Kanban teams; Scrum teams should stick to the sprint burndown.
Reality: CFDs are valuable for any team with a multi-stage workflow, including Scrum teams. Many Scrum teams operate a mini-Kanban board within each sprint. The CFD applied at sprint scope reveals which stage (dev, review, test, acceptance) absorbs the most time — information the burndown entirely hides. Progressive Scrum teams use both charts together.
Senior engineer insight
Teams who get real value from CFDs treat the chart as a conversation starter, not a reporting artefact — they look at it for 30 seconds before standup and come in with one specific observation: "the 'In Review' band has widened every day this week." Teams who struggle treat it as optional wallpaper, generating the data automatically in Jira and never opening the tab. The pattern that actually works is pairing the CFD with a WIP limit you enforce: without a limit, a widening band is just the natural result of unconstrained intake; with a limit, a widening band is an anomaly that demands explanation.
The most common mistake: reading the CFD after something has already gone wrong, rather than weekly as a flow health check that catches problems while they are still small.
From the field
A Wellington government agency running a welfare entitlements platform on Kanban assumed their delivery was healthy because items were always moving — standups were positive, developers were busy, and the backlog was growing. A new Delivery Lead pulled up the CFD in Jira (which had been auto-generating data for four months) and discovered the "In Test" band had quietly doubled in width over six weeks while the "In Dev" band stayed flat. The team had been starting new development work whenever anything was blocked in test, accidentally routing around their bottleneck instead of resolving it. Once they saw the shape, they imposed a WIP limit of three on "In Test" and stopped allowing new work into dev until the test queue drained — throughput to "Done" improved by roughly 40% within three weeks without adding a single person. The lesson: motion is not flow, and a CFD makes the difference visible long before the delivery manager notices delivery has stalled.
Why teams fail here
- Treating the CFD as a passive reporting tool rather than an active diagnostic — the chart updates automatically, so teams assume someone must be watching it when nobody is.
- Using too many workflow stages (8–10 Jira columns) so the CFD becomes a multicoloured mess where no single band's trend is readable — the fix is collapsing low-value waiting states before you need the chart.
- Identifying a widening band and labelling it a "resourcing problem" without investigating whether WIP limits, batching behaviour, or rework loops are actually the driver — data without root cause analysis leads to the wrong fix.
- Comparing CFD shapes across teams or projects — different workflow definitions, item sizes, and team compositions produce completely different chart shapes, so a "worse-looking" CFD may represent a healthier team depending on context.
Key takeaway
A CFD done well is a team's conscience: it cannot lie about where work is piling up, so the only question is whether you look at it often enough to act while there is still time to change course.
How this has changed
The field moved. Here is how Cumulative Flow Diagram evolved from its origins to current practice.
Cumulative flow diagrams originate in lean manufacturing. Don Reinertsen and David Anderson bring them from physical production to software as a way to visualise WIP and cycle time.
David Anderson introduces Kanban for software development. The CFD becomes the primary diagnostic tool — revealing WIP accumulation, process bottlenecks, and scope changes as shapes in cumulative bands.
Kanban tools begin providing automated CFD generation from ticket workflow data. Manual construction is no longer required. Teams view real-time CFDs without data collection effort.
Analytics frameworks formalise CFD interpretation — a widening band indicates WIP accumulation, parallel lines indicate blocked flow. Teams use CFDs for delivery date forecasting via Monte Carlo simulation.
AI-powered flow analytics interpret CFD patterns and diagnose bottlenecks without manual analysis. Predictive flow modelling suggests whether a target delivery date is achievable based on current flow metrics.
Self-Check
Click each question to reveal the answer.
Q: Your team is delivering a new benefit application portal for Benefits NZ. The "In Test" band on your CFD has been widening for three weeks while "In Dev" has stayed narrow. What does this tell you, and what action would you take?
A: A widening "In Test" band against a stable "In Dev" band means development throughput is consistently outpacing test throughput — a classic testing bottleneck. For a high-stakes government portal like Benefits NZ's, this is critical to surface early because benefit application logic often carries significant edge-case risk. The action is to bring the ratio to the retrospective with the CFD as evidence, quantify the gap (e.g. dev completes 8 stories per week, test completes 5), and propose either a WIP limit on "In Dev" to slow the inflow, or additional test resource to match capacity. Using the CFD to make the capacity argument with data is far more persuasive to a delivery manager than saying "testing feels behind."
Q: What is the key difference between a Cumulative Flow Diagram and a sprint burndown chart, and when would you choose one over the other?
A: A burndown chart shows a single line of remaining work declining toward zero — it answers "how much is left?" for a fixed sprint scope. A CFD shows multiple bands representing each workflow stage over time — it answers "where is work getting stuck?" for continuous flow. Choose the burndown when you need to track sprint commitment and communicate progress against a fixed deadline. Choose the CFD when you need to diagnose bottlenecks, monitor WIP trends, or manage continuous delivery without fixed sprint gates. Many experienced NZ teams run both: the burndown for sprint reporting to stakeholders, and the CFD for internal flow health checks in retrospectives.
Q: A developer on your TransitNZ road-tolling project says, "I checked the CFD and our lines are perfectly parallel, so our process is fine — no action needed." What is wrong with this reasoning and how do you respond?
A: Parallel lines confirm flow is stable, not that flow is fast or good enough. A CFD with perfectly parallel bands but a very shallow slope means throughput is low — work is moving predictably slowly through every stage. For a tolling system with a fixed delivery date, stable slow flow is still a risk. The response is to check the slope of the "Done" line against the delivery commitment: if the team is completing two stories per week but the release needs 20 more stories in six weeks, stable parallel lines are not reassuring. Always pair CFD shape analysis with throughput rate and lead time metrics before concluding the process needs no change.
Q: When would a CFD be an inappropriate or misleading tool to use as the primary flow diagnostic?
A: A CFD loses diagnostic value when workflow stages are inconsistently defined or teams routinely move items backwards through columns (e.g. from "In Review" back to "In Dev"), because the cumulative counts become unreliable. It is also misleading on teams where work items vary enormously in size — a CFD treats a one-hour task and a three-week feature as the same unit, so band widths reflect item count rather than actual effort. On very short-lived projects of three weeks or less, there is insufficient data for meaningful trend analysis. In these situations, a cycle time scatter plot with item-level data, or a simple task board with daily standups, gives a more honest picture of flow health than a CFD that appears to show stability due to low data volume.