Cumulative flow diagrams keep track of how issues move across each of your team's pipelines within each ZenHub Workspace you work in.


As issues flow across the Board, use the diagram to visualize issue throughput. Throughput helps teams track not only how much work is accumulating within each pipeline across a set date range, but also helps shed light on bottlenecks and areas for process improvements.




Get familiar with the basics of the Cumulative Flow Diagram

Regardless of the methodology your team uses, because work is organized in stages and workflows, the Cumulative Flow Diagram surfaces process improvement opportunities and process bottlenecks. Understanding where work is accumulating is powerful to help teams ensure a streamlined movement of work across any release cycle. 


Here's a few ways the Diagram helps teams:

  • Manage stakeholder expectations about the volume of work that's actually moving throughout your development cycle. Instead of relying on guesses, the Diagram surfaces your team's throughput in a quantifiable way. 

  • If you're not using estimation in your workflow, the Diagram still helps you visualize how work is being completed in a time-boxed release, as well as if issues are getting caught up within a particular workflow stage.

  • Teams can see where work gets blocked.

  • Teams get a historical look into progress and how many issues have flowed throughout their workflow


Each color represents a different pipeline, or workflow stage.

The diagram is "cumulative" because it’s not measuring incremental changes being added and removes across time frames, but rather flow of data points. Once a data point enters the chart, it moves throughout the chart, but will never be removed (like an incremental change). Data points stay the same, tracked regardless of when you look at the diagram: each issue gets counted once it's created, it will just be in a different pipeline the next time you look at it.


The difference between throughput and bandwidth.

Commonly, a Cumulative Flow Diagram is used for tracking throughput. Throughput should not be confused with bandwidth! Bandwidth is the maximum amount of things you think you can take on, where as throughput is the actual amount that was completed.


The Cumulative Flow Diagrams helps teams understand how many issues are in each pipeline, how this changes over time, and surfaces bottlenecks.

The diagram shows the number of issues in each pipeline as a “stack or band” to help you identify over a period of time. As each band of issues rises and falls, you're able to understand how many issues got “stuck” or are within that pipeline versus other pipelines at any given time (and over time).


Reading the Cumulative Flow Diagram

In most workflows, there’s 4 core stages:

  • New work (ie. Triage, Icebox)

  • Planned work (ie. Backlog, Sprint Backlog)

  • Work in progress (ie. In progress, code review, QA)

  • Completed work (ie. Done, Closed)



Each “stage” may be made up of 1 or more pipelines in ZenHub. While the granular pipelines might change, these stages are how work moves throughout most team’s software cycles. As work flows from stage-to-stage, they'll shift pipelines, causing the different bands to grow and shrink accordingly. 


Understanding the axis' of the chart

The x-axis (along the bottom) is time. Over time, issues will flow from the top left band to the bottom right (or Closed) pipeline. Along the y-axis (up and down) is the number of total issues on the Board. Each band will be as "big" as the sum of issues in each pipeline. All pipelines summed up (that are toggled on) represents the total number of issues that, within the selected time frame, were on the Board.


We share below more on what an ideal Diagram looks like as these movements occur, as well as what to look out for periodically.


What’s the ideal diagram look like?

Ideally, Cumulative Flow Diagrams have an upwards-to-the-right slope with even colored bands. This represents that across all pipelines (with the exception of the Closed pipeline) the same amount of issues roughly flow through each stage, at all times.


Your Closed pipeline should always continuously get bigger, which means you’re closing more work :)!



Toggle off pipelines that are reference/catch-all stages in your workflow

To assess the flow of issues, keep only those pipelines toggled on that represent actual movement. In the example above, the On Ice pipeline is toggled off because that's an ideas-hold. issues will still flow in-and-out, but it's more a reference pipeline in the context of the rest of the pipelines. 


If you're assessing how long issues stay in the Icebox, or if you're continuously chipping away at it, do keep it toggled on! But if you're assessing the flow of Planned Work › Work in Progress › Done, it's best to turn it off to analyze the slope and flow of work throughout your Board.


Diagram details to look out for 


Rapid growth of some pipelines

If you are seeing any one pipeline stack up, or grow rapidly in size on a particular date, or within a certain timeframe, this may mean this part of your workflow encountered bottlenecks, resource constraints, or something was preventing work from moving forward to the next pipeline during that time. 


A common example: Over Christmas, your Up Next pipeline grew rapidly but In Progress shrunk or stayed the same. This meant little work got worked on: naturally, people were away that Sprint for the holidays. But you had a lot ready to go! It’s the holidays, so naturally this type of Diagram visualization is to be expected. But, if this occurred during a normal sprint, dig into what issues got stuck and why. 


Here's some questions you might want to dig into:

  • Was there unexpected work on issues in flight that were not accounted for during planning? 
  • Did work get done, but was not logged in the Board as an issue therefore isn't being counted as in progress?
  • Was there time off taken, or resources shifting that took time away from planned work being started?


A variation of BIG bands, paired with other small bands. 

This may mean there’s a bottleneck. The growth of one stage, but the shrinking of the stage right after it means there's not a consistent flow across workflow stages. Perhaps you’re coming up with more ideas or work items than you're closing. Or, your team is accepting more into the Sprint without removing other items. It could even be that perhaps you're not finishing testing work before starting new work. 


A healthy Diagram means each pipeline stage is relatively the same size as the others around it. If you notice the big/small band variations, here's a few next steps to consider based on the situation:

  • A growing Sprint Backlog, without a growing In Progress pipeline: Review how you accept work into the Sprint / go about planning. Be rigorous about not allowing Sprint interruptions (apart from high priority items. Take extra time to plan, test, and review before accepting new work into the Sprint)
  • A growing In Progress pipeline, but small Code Review pipeline: Establish work-in-progress limits. No work can be started until the remaining work is code-review-complete. Since Code Review / Testing is still an "in progress" issue, no new work should be taken on until that work item has cleared your team's definition of "in progress".



  • A growing QA phase, but flat-lined Closed / Done state: Review how you QA issues and also establish work-in-progress limits. Perhaps it's time to redefine your QA process, bring on additional testing support!
  • A growing Backlog: Review how you pull work into progress, be diligent about saying no to ideas you know don't fit your roadmap or vision, and continuously have refinement sessions to keep the backlog clear. 


Your In Progress pipelines drastically change

Your In Progress (or equivalent pipeline) should never drastically widen, but stay consistently the same size. Unless of course you add more team members! 


When there's a drastic increase for in-flight issues, but no change in completed work, you might encounter context switching, lessened productivity, or that work doesn't get completed as quickly as normal. When too much work gets started but not finished, the likelihood grows that individuals encounter multitasking.

The number of issues the team takes on shouldn’t change drastically without the exception of hiring new team members. If the number of issues in progress is too large, there’s context switching, potential to not finish work, and projects will likely be delayed. Any sudden growth in this area of the Diagram should spur conversations around why there’s suddenly more in-flight.


Your sprint backlog is growing, but your work in progress stages are not

When you notice a growing sprint backlog, but the pipeline stages that represent your stages of in progress do not grow alongside the backlog, this means you're accepting more work in to your sprint, modifying your expected Velocity, without actually improving throughput. 


To ensure your sprint backlog doesn't grow over time, establish a buffer in your sprint, taking on 10% less velocity each Sprint and check whether you're continuously bumping work sprint-to-sprint. We share additional tips on managing sprints and running effective sprint planning sessions here.



When every band starts increasing quite rapidly with a very sharp curve up-to-the-right

The ideal Diagram has a nice upwards-to-the-right curve. When this curve drastically becomes more steep, there might have been deadline pressure, bad habits with moving and updating issues, or a final push to finish a key feature.


This might not be a bad thing, as you may be working on a final project push, but if you have a lot of rapid movement across your Board in a short time duration, review how you keep issues updated, chat about why this steep curve has appeared, and ensure that it's a positive reason!



More on how ZenHub populates the Cumulative Flow Diagram

  • The Cumulative flow auto-populates! All you have to do is move work across the Board. Teams do not need to use estimation to unlock the Diagram. You just need to have issues on the Board.
  • They automatically historically populate with the last 3 months of data.
  • Teams will have pre-set date filters.

    • 14 days (Common Sprint length)

    • 30 days (Typical length of time it takes to onboard new process habits)

    • 3 months (Common goal timelines/project roadmap planning cycles)

    • 6 / 12 / 24 months (Helps with analyzing long-term process efficiency)

Share your Cumulative flow diagram

When viewing your Cumulative flow diagram, you can share by copying the link, or export the report to CSV to further customize and analyse data. To generate the shareable link or export the report, navigate to your cumulative flow diagram where there is a Share button located in the top right of the report page next to the report title: