Flow Analytics · March 15, 2026 · 8 min read · By Henry Sword

How to Read a Cumulative Flow Diagram in Azure DevOps, From Sprint to Epic

A cumulative flow diagram shows how many items sit in each workflow stage on each day. This guide covers how to read the bands, what widening bands and flat lines mean, how to build an Epic or Feature CFD in Azure DevOps, and how the built-in CFD compares with the sprint CFD in Agile Analytics.

  • #cumulative flow diagram
  • #CFD
  • #epic cumulative flow diagram
  • #flow analytics
  • #WIP
  • #workflow
  • #azure devops

A cumulative flow diagram (CFD) counts the work items in each stage of your workflow on each day and stacks the counts into bands. Time runs left to right. The bottom band is finished work, the top band is work nobody has started, and everything in between is work in progress. You do not read a CFD for exact numbers. You read it for shape: which band is growing, which is flat, and where the gaps open up.

How to read the bands

Three measurements come straight off the chart once you know where to look.

  • The vertical thickness of a band on a given day is the number of items in that stage on that day. Add up the middle bands and you have work in progress.
  • The slope of the top edge of the Done band is throughput. A steep slope means items are finishing quickly. A shallow slope means few are.
  • The horizontal distance between the line where items enter progress and the line where they reach Done is roughly how long an item takes to get through. It is an approximation, so use a cycle time chart when you need the actual number.

Widening bands

A band that gets thicker over time means items are arriving in that stage faster than they leave it. If the widening is in an active stage such as In Progress, the team is starting more than it finishes. If it is in a stage like Test or Review, that stage has become the bottleneck: work is waiting for a person or an environment. Widening in the not-started band is less urgent. It usually means the backlog is growing faster than the team pulls from it, which is a planning question rather than a flow problem.

  • Find the first band from the bottom that widens. The stage just after it is often where work is getting stuck.
  • Do not try to fix every band at once. Start with the stage closest to Done, because nothing upstream speeds up while it is blocked.

Flat lines

A flat Done band means nothing finished for that stretch of days. A flat band anywhere else means the items in that stage did not move. One or two flat days are normal, especially across a weekend. A flat week usually has one of three causes: the team is blocked on something outside its control, the work items are not being updated as work moves, or the items are too large to finish in a few days. The first needs the owner of the dependency, the second a team habit, the third better slicing at the next planning session.

Steps and narrowing

A sudden step, where a band jumps up or down by several items on one day, means a batch of items moved together. That is often someone tidying the board at the end of the sprint rather than real work. If you see steps at every sprint end, the CFD is telling you more about update habits than about flow. A band that narrows after being wide is good news: a queue is draining, usually after a blocker cleared. Bands that converge on the right side of a sprint chart mean the sprint is closing out its work.

Epic and Feature cumulative flow diagrams

A CFD of Epics or Features reads the same way, but on a longer timescale. An Epic may sit in an active state for months, so a sprint-length window shows nothing but flat bands. Use a window of three to six months. The most useful band on an Epic CFD is the in-progress band: its thickness is the number of Epics the organisation has open at the same time. If that number keeps rising while the Done band stays flat, the portfolio is starting initiatives faster than it finishes them, and every one of them is moving slowly as a result. That is the portfolio version of a team starting too much.

  • Expect steps. A portfolio CFD has few items, so each Epic that changes state moves a band by one, and the chart looks stepped rather than smooth.
  • Compare the in-progress band with the number of teams. Many more open Epics than teams usually means work is spread too thin.
  • Pair it with a Feature CFD for the same period. Features finishing steadily under Epics that never close often means the Epics are too large or have no clear finish line.

Building an Epic CFD in Azure DevOps

For Epic and Feature level flow, use the CFD that Azure DevOps already provides. It works on product and portfolio backlogs and reads from the Azure DevOps Analytics service. There are two ways in:

  • The in-context report: open Boards, then Backlogs, pick your team, switch the backlog level to Epics or Features, and select Analytics, then View full report. You can choose a rolling period of 14 to 180 days, swimlanes and board columns.
  • The Cumulative Flow Diagram widget on a dashboard: in its configuration, pick the Team, the Backlog level, the Swimlane and the Columns, then either a rolling period in days or a fixed start date.

The built-in CFD and the Agile Analytics CFD

The two are built for different jobs. The built-in CFD is the right tool for long windows and for portfolio levels. It follows your board columns and swimlanes, and it can sit on a dashboard. The Cumulative Flow view in Agile Analytics (under Measure in the hub) is built for a single sprint of a single team. You pick a Team and a Sprint, select Build CFD, and it draws that sprint from the first day to today, or to the sprint end for a past sprint. It does not have an Epic or Feature level, and it does not have a date range picker. Epics and Features have their own views in the hub, Epic Analytics and Feature Analytics.

What the sprint CFD in Agile Analytics shows

The chart is built by replaying each work item’s state history day by day, so it shows where every item was on each day of the sprint, not where it sits today. For a past sprint, the set of items in the sprint is rebuilt for each day too. States are placed into seven bands, from the bottom: Done, Review, Test, In Progress, Waiting, Queued and New. Which state goes in which band comes from Configuration → Workflow Mapping, so custom state names land in the right place. States that are not mapped are left out of every band, and a notice lists them so an admin can map them.

  • Hover a day to see the count in each stage. Each band is also labelled with its current count on the right edge.
  • Click a stage in the legend to show or hide its band, for example to look at the active stages without Done.
  • Ticks mark the days on which items were completed.
  • Orange dashed lines mark the days when items were added after the sprint started, with a +N count. Click a line to open those items in Azure DevOps.
  • A summary strip above the chart gives a verdict (Flow: Steady, Flow: WIP climbing or Flow: Stalled) and tiles for Completed, WIP now (against 3 days ago), Throughput per day, Not Started and Scope Added. WIP counts In Progress, Test, Review and Waiting.
  • Export CSV writes one row per day with the count in each stage.

A short routine for using a CFD

A CFD is most useful when someone looks at it at the same point every week, not when it is pulled up to explain a missed date.

  • Mid-sprint, open the sprint CFD and look at WIP now against three days ago. If it is climbing, ask what the team can finish before it starts anything new.
  • Look for any active band that is wider than it was at the start of the sprint, and name the stage at the standup.
  • Once a month, open the Epic level CFD in Azure DevOps and count the open Epics against the number of teams.

Related: Cycle time and WIP explained · Azure DevOps flow metrics · Workflow mapping setup guide · Work item aging chart for standups

Need more than a blog explanation?

Flow buyers usually want cycle time and WIP monitoring next. Use the use-case page or go directly to plan comparison.

Related reading

Find our articles faster: add Agile Analytics as a preferred source in Google Search.Add preferred source →