I used Agile & Scrum to build my own app — Nutrify AI is FREE for all my students today! Try it on iOS →

Cumulative Flow Diagrams: Complete Guide 2026

Scrum Metrics and Reporting: Cumulative Flow Diagrams

A Cumulative Flow Diagram (CFD) is a powerful visual tool that shows how work items flow through the stages of your workflow over time.

Unlike a Burn Down Chart that shows remaining work versus time, a CFD shows the total cumulative count of items at each workflow stage - making bottlenecks, flow efficiency, and work-in-progress limits visible at a glance.

CFDs are widely used by both Scrum and Kanban teams because they answer critical questions:

  • Where is work getting stuck?
  • How long does it typically take for a story to go from start to done?
  • Is our work-in-progress growing out of control?
  • Are we delivering at a consistent rate?

Quick Answer: Cumulative Flow Diagrams at a Glance

AspectDetails
What it showsCumulative count of work items in each workflow stage over time
Key insightBand width = WIP in that stage; band slope = throughput rate
Horizontal distanceApproximate cycle time for work items
Vertical distanceApproximate WIP at a given point
Best forBottleneck detection, flow efficiency, WIP control
Vs. BurndownCFDs show flow health; burndowns show sprint progress toward a goal

Understanding Cumulative Flow Diagrams

A Cumulative Flow Diagram consists of several colored bands, each representing a different stage in the workflow.

  • The horizontal axis represents time (days, weeks, or sprints)
  • The vertical axis represents the cumulative count of work items
  • Each colored band represents a workflow stage (e.g., To Do, In Progress, In Review, Done)

The top line of the diagram shows the total number of items that have entered the workflow. The bottom line (usually the "Done" band) shows items completed. The area between them represents work in various stages.

In a healthy CFD, all bands should have roughly consistent widths over time. If one band grows wider (accumulates more items) while others stay flat, that stage is a bottleneck.

The power of the CFD comes from reading it in three ways simultaneously: band width, slope, and distance.

How to Read a CFD: The Three Key Dimensions

Band Width: Work in Progress

The width of each band (measured vertically at any given point in time) represents the number of work items currently in that stage.

  • Narrow band: Few items in this stage at any given time (good for flow)
  • Wide band: Many items in this stage (potential bottleneck or high WIP)
  • Growing band: More items entering this stage than leaving (accumulation = bottleneck forming)
  • Shrinking band: Items leaving this stage faster than they enter (throughput exceeding input)

Example: If the "In Code Review" band grows from 2 items wide to 8 items wide over two weeks, code review is becoming a bottleneck. More work is arriving for review than is being reviewed and passed.

Slope: Throughput Rate

The slope of each line shows how quickly items are moving through that stage:

  • Steep upward slope: High throughput - items are moving through quickly
  • Flat line: Zero throughput - no items are completing this stage (blocked)
  • Gentle slope: Low throughput - items moving slowly

The top line (total items in system) and bottom line (items Done) should have roughly parallel slopes in a healthy system. If the top line rises steeply while the bottom line stays flat, work is entering the system faster than it is being completed.

Horizontal Distance: Cycle Time

The horizontal distance between the top and bottom lines at any given vertical position approximates the average cycle time - how long it takes for a work item to travel from entry to done.

  • If you draw a horizontal line from the point where an item entered the system to where it exits (Done), that distance represents its cycle time.
  • A widening gap (longer horizontal distance) indicates increasing cycle time - items are taking longer to complete.
  • A narrowing gap indicates improving cycle time - work is flowing faster.
⚠️

Cycle time in a CFD is an approximation. For precise cycle time measurement, track the actual start and end dates of individual items. CFDs give you the trend, not the exact number.

Benefits of Cumulative Flow Diagrams

CFDs provide several benefits for Scrum teams:

  • Monitor progress: CFDs help teams track the progress of work items through different stages, making it easy to see if the team is on track to meet their goals.

  • Identify bottlenecks: If the width of a band widens over time, it indicates that work items are accumulating in that stage - signaling a bottleneck that the team should address.

  • Improve predictability: By analyzing the trends in a CFD, teams can make better predictions about when work items will be completed and adjust their plans accordingly.

  • Visualize WIP: CFDs make work-in-progress visible, helping teams identify when they have too much work in flight and need to focus on finishing before starting new items.

  • Measure flow efficiency: The relationship between the slopes of the top and bottom lines reveals whether the team is delivering at a consistent rate or experiencing significant delays.

  • Detect scope creep: A steep rise in the top line relative to the bottom line signals that new work is entering the system faster than it is being completed.

How to Create a CFD from Sprint Data

Building a CFD manually from sprint data is straightforward:

Step 1: Define Your Workflow Stages

Start by listing all the stages in your workflow. For a typical Scrum team:

  • Product Backlog (To Do)
  • In Development
  • In Code Review
  • In Testing
  • Done

Keep the stages at a meaningful granularity - 3 to 6 stages is ideal. Too few stages hide important flow information; too many make the chart cluttered.

Step 2: Count Items in Each Stage Daily

Each day, record the count of items in each stage. In most tools, this is automated. Manually, you can count items on your task board at the end of each day.

Example daily snapshot:

DateTo DoIn DevIn ReviewIn TestingDone
Day 1203110
Day 2184210
Day 3173311
Day 4155221
Day 5135214

Step 3: Calculate Cumulative Counts

For the CFD, you need cumulative counts - the running total of items that have reached or passed each stage:

  • Cumulative Done: Items completed to date
  • Cumulative In Testing or Done: Items that have entered testing (whether done or still in testing)
  • And so on upward through each stage to the total items in the system

Step 4: Plot the Bands

Plot cumulative counts for each stage over time as stacked area chart. Each colored area represents a workflow stage. The bands stack on top of each other so the top line represents the total items in the system.

Step 5: Review Daily or Weekly

In Scrum, review the CFD at the Daily Scrum or weekly in the Sprint Review. Look for:

  • Widening bands (bottleneck forming)
  • Flat lines (blocked stage)
  • Diverging top and bottom lines (increasing cycle time)

CFD Patterns and What They Mean

Pattern 1: Smooth Parallel Bands (Healthy Flow)

All bands have roughly consistent widths and similar slopes. Work flows through each stage at roughly the same rate. This is the ideal state.

What to do: Maintain current practices. Continue monitoring for early signs of change.

Pattern 2: Widening Band (Bottleneck)

One band grows progressively wider over time while others stay constant. Work is accumulating in that stage faster than it exits.

What to do: Focus team attention on the bottlenecked stage. Apply the Theory of Constraints: add capacity to that stage, reduce WIP entering it, or remove blockers. Do not start new work upstream until the bottleneck is resolved.

Pattern 3: Flat Line (Complete Block)

One of the bands' upper boundaries becomes completely horizontal - no new items are completing that stage.

What to do: This is a serious signal. Immediately identify what is blocking the stage. Is a team member sick? Is there a dependency on an external team? Is there a technical blocker? Escalate and resolve as a top priority.

Pattern 4: Expanding Gap (Increasing Cycle Time)

The horizontal distance between where work enters and where it exits (Done) grows over time. Items are taking longer and longer to complete.

What to do: Investigate the cause. Common causes include: increasing WIP (too many items started at once), technical debt slowing progress, unclear requirements causing rework, or external dependencies.

Pattern 5: Staircase (Batch Releases)

The "Done" line stays flat for extended periods, then jumps up sharply. Items are being completed but not released or counted as Done until a batch release.

What to do: If possible, implement more frequent releases or update the Definition of Done to count items when they are functionally complete rather than when they are externally released. Batching reduces feedback quality.

Pattern 6: Diverging Lines (Scope Creep)

The top line rises steeply while the bottom line stays relatively flat. New work is being added to the system significantly faster than work is being completed.

What to do: Have a conversation with the Product Owner about WIP limits and scope discipline. Consider implementing an explicit input limit to the system - no new items start until current items are finished.

Identifying Bottlenecks and Flow Issues

The CFD is uniquely powerful for bottleneck identification. Here is a systematic approach:

The Theory of Constraints Approach

  1. Identify the constraint: Find the widening band on the CFD - that is your current bottleneck.
  2. Exploit the constraint: Make the most of the bottleneck's current capacity. Reduce interruptions, remove non-essential tasks, and ensure it is fully utilized.
  3. Subordinate everything else: Do not let upstream stages overload the bottleneck. If the constraint is In Review, stop starting new development stories until the review queue clears.
  4. Elevate the constraint: If exploitation is not enough, add capacity (pair programming on reviews, add a reviewer, automate part of the review).
  5. Repeat: Once one bottleneck is resolved, find the next one and repeat.

Common Bottleneck Indicators in Scrum

  • In Code Review band widens: Too few reviewers, reviews are too slow, or review standards are unclear.
  • In Testing band widens: Testing is happening at the end of the sprint (not continuously), too few testers, or test environments are unavailable.
  • In Product Owner Review band widens: Product Owner is unavailable or overloaded with review requests.
  • To Do band grows: Sprint scope is being added faster than work is being completed (scope creep).

Using CFDs in Scrum

In Scrum, teams can use CFDs to visualize the flow of Product Backlog Items (PBIs) through different stages, such as "To Do," "In Progress," and "Done."

CFDs in Sprint Planning

Use the CFD from previous sprints to identify:

  • Which stages consistently have the highest WIP (and therefore should have explicit WIP limits set)
  • Average cycle time per story type (useful for capacity planning)
  • Whether the team tends to finish work in batches at sprint end (cliff pattern in burndown)

CFDs in the Daily Scrum

A CFD updated daily provides an excellent conversation starter:

  • "The In Review band has grown to 5 items - that is our highest ever. Who needs help with reviews today?"
  • "Our cycle time is increasing. Let us focus on finishing items in flight before starting new ones."

CFDs in Sprint Review

Present the CFD in the Sprint Review to show stakeholders:

  • The volume of work that flowed through the system
  • Any significant bottlenecks encountered during the sprint
  • Trend in cycle time over the last 3-5 sprints

CFDs in Sprint Retrospective

Use CFD data in retrospectives to drive specific improvement actions:

  • "Our CFD shows In Testing consistently widening. Let us discuss adding testing early in the sprint rather than at the end."
  • "Our cycle time has grown from 3 days to 7 days over the last 4 sprints. What changed?"

CFD vs. Burn Down Chart: When to Use Each

DimensionBurn Down ChartCumulative Flow Diagram
Primary question"Will we finish the sprint?""Where is work getting stuck?"
Time horizonSprint level (days)Sprint or product level (weeks)
Update frequencyDailyDaily
Shows WIPNoYes
Shows bottlenecksNoYes (band width)
Shows cycle timeNoYes (horizontal distance)
Shows scope changesPartially (chart spikes)Yes (top line rises)
Team familiarityHigher (simpler)Lower (requires learning)
Best audienceTeam (daily)Team + management (strategic)

Use Burn Down Charts when: You need a simple daily team progress indicator for the current sprint.

Use CFDs when: You want to understand flow efficiency, identify systemic bottlenecks, track cycle time trends, or provide richer metrics to stakeholders.

Best practice: Use both. The burn down chart provides sprint-level granularity; the CFD provides the systemic view.

Common CFD Mistakes

Mistake 1: Too Many Workflow Stages

Problem: Teams add 10+ stages to their CFD, making it unreadable.

Why It's Problematic: The chart becomes a color explosion that no one can interpret meaningfully. Subtle patterns become invisible.

Fix: Limit CFD stages to 3-6 meaningful workflow steps. Combine minor stages (e.g., merge "Waiting for Review" and "In Review" into a single "Review" band) unless the distinction is important for your process.

Mistake 2: Updating the CFD Weekly Instead of Daily

Problem: Teams only snapshot their board state at the end of each week.

Why It's Problematic: Daily fluctuations and short-lived blockages are invisible. By the time the weekly snapshot is taken, a 3-day blockage may have already resolved.

Fix: Update the CFD daily, even if only a count change. Most tools do this automatically.

Mistake 3: Ignoring the Widening Bands

Problem: Teams see a band growing but do not act until the sprint is almost over.

Why It's Problematic: Bottlenecks compound over time. Waiting allows the queue to grow and cycle time to increase significantly.

Fix: Set a WIP limit threshold for each stage. If any stage exceeds its limit, the team swarms to address it before starting new work.

Mistake 4: Not Including All Work Types

Problem: Teams only track feature stories on the CFD, omitting bugs, technical debt, and spikes.

Why It's Problematic: A significant portion of team capacity is invisible. The "Done" rate appears lower than reality, and bottlenecks in bug-fix or tech-debt work are missed.

Fix: Include all work types on the CFD. Use colors or symbols to distinguish types within the same workflow stages if needed.

Mistake 5: Conflating Cycle Time with Lead Time

Problem: Teams use CFD horizontal distance as the customer-facing lead time.

Why It's Problematic: CFD horizontal distance approximates the time an item spends in the workflow stages shown. If "backlog waiting" is not included in the CFD, the real lead time is longer.

Fix: Distinguish clearly between cycle time (time from start-of-work to done) and lead time (time from customer request to delivery). Ensure your CFD's leftmost stage reflects the correct starting point for your measurement.

Mistake 6: Creating CFDs That No One Reviews

Problem: CFDs are generated automatically by tools but never actually discussed in team meetings.

Why It's Problematic: Data without action is waste. The CFD's value comes from the conversations and improvements it triggers.

Fix: Explicitly include CFD review as a regular agenda item in Sprint Retrospectives. Designate someone to present one key CFD insight per retrospective.

Mistake 7: Not Establishing WIP Limits Based on CFD Data

Problem: Teams use the CFD to observe bottlenecks but do not adjust their WIP limits in response.

Why It's Problematic: Without WIP limits, the bottleneck will recur in the same stage sprint after sprint.

Fix: Use the widest consistent band on your CFD to set an explicit WIP limit for that stage. This prevents the queue from growing and creates pressure to resolve bottlenecks earlier.

CFD Maturity Model

Stage 1: Observation (Sprints 1-6)

Characteristics:

  • CFD is created (manually or via tool)
  • Team is learning to read the bands
  • No formal WIP limits set
  • CFD reviewed occasionally but not systematically

Focus: Learn to read the chart. Identify which stage is consistently widest. Begin discussing bottlenecks.

Stage 2: Active Management (Sprints 7-15)

Characteristics:

  • CFD reviewed at Daily Scrum or at least weekly
  • WIP limits established based on CFD data
  • Team responds to widening bands proactively
  • Cycle time trend is tracked

Focus: Implement WIP limits and measure whether they improve flow. Use CFD patterns to drive retrospective actions.

Stage 3: Predictive Flow (Sprint 16+)

Characteristics:

  • CFD used for delivery forecasting alongside velocity
  • Cycle time and throughput data supplement story point velocity
  • WIP limits enforced as a process discipline
  • CFD shown to stakeholders as part of program reporting

Focus: Use CFD insights to optimize the entire delivery system, not just individual sprints. Integrate CFD data with release planning and stakeholder communication.

Industry-Specific CFD Applications

SaaS/Cloud Services

  • Track stages from "Feature Requested" through "Deployed to Production"
  • Monitor the "In Production Testing" band for canary deployments
  • Use CFD to track incident-related work items alongside feature work
  • Identify whether CI/CD pipeline stages create bottlenecks (e.g., long build times)

Healthcare Software

  • Include compliance review stages in the CFD workflow
  • Track PHI-touching features through separate security review lanes
  • Monitor clinical validation stages to prevent approval delays from creating a bottleneck
  • Use the CFD to show regulators evidence of controlled, auditable delivery flow

Financial Services

  • Include fraud detection and compliance testing as explicit CFD stages
  • Track regulatory change requests separately from product features
  • Use CFD cycle time data to forecast audit preparation timelines
  • Monitor for batching behavior (staircase pattern) in compliance-dependent releases

E-commerce

  • Track from "User Story" through "A/B Test Validated" and "Fully Released"
  • Include performance testing as a CFD stage (common bottleneck)
  • Monitor seasonal work patterns - how does WIP change pre-holiday versus off-season?
  • Use CFD to identify whether mobile and web features have different cycle times

Mobile Apps

  • Include app store submission and review as a CFD stage
  • Track the "Waiting for App Store Approval" band (uncontrollable delay)
  • Monitor compatibility testing across device types as a potential bottleneck
  • Use CFD to distinguish cycle time for platform-specific features vs. shared features

Enterprise DevOps

  • Track work from "Backlog" through "Deployed to Production" including infrastructure changes
  • Include change advisory board (CAB) review as a CFD stage if applicable
  • Monitor security scanning and penetration testing as potential bottleneck stages
  • Use CFD to identify whether manual deployment steps create batching behavior

Tools for Creating CFDs

ToolCFD SupportNotes
JiraBuilt-in CFDAvailable in Scrum board reports; configurable workflow stages
Azure DevOpsBuilt-in CFDAvailable in Boards analytics; multiple team views
LinearLimitedCycle time charts available; full CFD via export
TrelloVia pluginsPlus for Trello and similar plugins
GitHub ProjectsNo native CFDUse exports + external analysis
Actionable AgileFull CFD + analyticsPurpose-built for flow metrics; integrates with Jira/Azure DevOps
Tableau / Power BICustom CFDFrom exported data; maximum flexibility
Excel / Google SheetsManual CFDFrom daily snapshots; appropriate for small teams

Actionable Agile Analytics (now part of Nave) is considered the gold standard for CFD analysis in Agile teams. It provides Monte Carlo simulations for delivery forecasting directly from CFD data.

Conclusion

Cumulative Flow Diagrams are a powerful tool for Scrum teams, providing insights that burn down charts cannot: bottleneck identification, cycle time trends, WIP visibility, and flow efficiency.

By understanding and using CFDs effectively, Scrum teams can:

  • Identify and eliminate bottlenecks before they derail sprints
  • Maintain healthy WIP levels that support steady flow
  • Forecast delivery dates based on actual throughput rather than estimates alone
  • Have data-driven conversations about process improvement in retrospectives

Key takeaways:

  • Band width = WIP in that stage (wide = bottleneck)
  • Slope = throughput rate (flat = blocked)
  • Horizontal distance = cycle time (growing gap = slowing down)
  • Use alongside burn down charts, not as a replacement
  • Review daily in Daily Scrum, strategically in retrospectives
  • Set WIP limits based on your CFD data to prevent bottleneck recurrence

Quiz on Cumulative Flow Diagrams

Your Score: 0/15

Question: What does the width of a band in a Cumulative Flow Diagram represent?

Continue Reading

Frequently Asked Questions (FAQs) / People Also Ask (PAA)

How do Cumulative Flow Diagrams work in pure Kanban systems compared to Scrum?

Can CFDs be used for release-level forecasting without story point estimation?

How do you handle CFDs when a team's workflow changes mid-project?

What is Monte Carlo simulation in the context of CFD and why does it matter?

How should CFDs be used in organizations with multiple Scrum teams working on the same product?

What is the relationship between WIP limits and Cumulative Flow Diagrams?

How do CFDs differ from cumulative value charts?

Can a team use CFDs effectively with a small number of work items?

How should a Scrum team respond if their CFD consistently shows increasing cycle time over multiple sprints?

Is it better to track story counts or story points on a CFD?

How do CFDs support Continuous Improvement in Scrum retrospectives?

What are the privacy and transparency considerations for sharing CFD data outside the Scrum team?

How do CFDs relate to the Scrum pillar of Transparency?

What is the difference between a CFD showing healthy flow and one showing an unhealthy system?

Can CFDs be used to evaluate whether a Definition of Done change improved quality?