Sample Cumulative Flow Diagrams and what they mean
To help teams pull insights from their own Cumulative Flow diagram data, we've shared different types of trends that might occur. Each chart has a description of key aspects of the diagram that you might also notice in your own charts and what to do if you do spot similar trends.
Flat durations for ~2 weeks, with large spikes
When you notice over a 14 or 30 day period that there are significant flat spots for more than a few days, this indicates that there is no flow of Issues across your Workflow. Here's a few trends from the diagram worth discussion:
- Between Sat the 15th and Mon the 30th, majority of the pipelines flatlined. When majority of your pipeline stages flatline, this means Issues entered this part of your workflow, but never progressed to the next pipeline. This could indicate bottlenecks or bad Board hygiene.
- You might be taking on too much work at once. Working on many Issues at once means they take exponentially longer to complete start-to-finish.
- You might be taking on Issues that overly complex, meaning they take twice as long to move between pipeline stages.
- Or, you could be completing work, but not updating it's pipeline state.
- There's a spike between the 30th and 2nd. When spikes occur, independent of flat periods, this could indicate a few things:
- The team is cleaning up a pipeline state or closing stale Issues (when you see the Closed pipeline also go up)
- You're waiting until a sprint or release is completed before moving Issues to closed. Having a different definition of done is a great thing so this spike would naturally fit with your process.
- Regardless of point in time, the "bands" (your pipelines) are relatively the same width along the entire diagram. This is a good insight! When the bands stay the same width, it means no one pipeline in your Workspace is accumulating work. You have a good flow of Issues throughout your workflow.
Analyzing the stages of your workflow that monitor Sprint progress
When looking at the last 14 days, or a custom time frame that mirrors that of a recent Sprint, you want to see am upwards trend to the right when looking at the Diagram. In the example below, there's a few trends starting to develop that might indicate you're taking on Issues that are too complex and not broken down enough. Here's a few trends:
- Between Wed the 26th and Tuesday the 2nd, there's no Issue movement. All pipelines that represent your Sprint backlog to completed are flat. Typically, this means work either was not done during this time frame, meaning no Issues got picked up. Or, you've taken on larger Issues that sat in their respective pipelines for quite some time. Given this example is over a seasonal break, this would be expected for this time duration. However, if you saw this occur during a Sprint where no holidays were planned, you might want to consider the size of work being tackled at the beginning of a Sprint.
- Between the 3rd and 8th, there's a nice upward curve and the Closed pipeline is getting bigger. This is what you want to see! This indicates work is nicely flowing through to completed.
- Last, each of the pipeline bands stay the same width throughout the whole time duration. This indicates that there are no bottlenecks in your process. Work is being picked up, moved pipeline-to-pipeline at the same rate as it's flowing into the next stage. This could indicate you have good work in progress limits.
- larger issues at the start?
Seeing flat lines over holiday breaks
During any downtime, holiday break, or otherwise resource-limiting period, you might see your Diagram show flat lines. Since this is typically when minimal work gets started or moved, this is to be expected.
In the example below, you can see a flatline from the 21st to 5th, a time when majority of the team was offline, and otherwise had a code freeze on. No code got released, therefore no Issues were moved. Overall, if you see flatline trends it's important to have a quick chat about whether this is expected given downtime, or if it's occurring because of resource constraints.
When your Icebox / Triage is large, it's type for Board hygiene
On the left side of this Diagram, there's a significantly large To be Triaged and Icebox grouping. Mid away through the chart, you can see this even-out and the triage pipeline gets small, while the Icebox and Backlog both grow.
When the first few pipelines in your Board start to drastically get wider over time, we recommend reviewing how you manage backlog management. In the example below, the Triage pipeline was being treated as the Icebox. This meant it was difficult to actually triage new incoming bugs, tech debt, feature work, and this critical product prioritization step was getting missed. This can have downstream impact on development throughput, as it doesn't afford the team the space to have scope and trade off conversations before work hits a Sprint.
Good Board hygiene keeps the later half of your workflow clean. Anytime your Triage or equivalent workflow stage starts to grow, consider assessing your team's process for analyzing Issues. You can also implement Issue templates for similar Issue types to streamline data people collect prior to submitting Issues. This can help keep triage clean, making it easy to maintain.
The Diagram below is what you want to see in your own charts. Here's a few trends that mean your process is smooth, the team has consistent throughput, and Issues are flowing well across the Board:
- Step-ups to the right are consistent. There's a nice steady growth in the Closed pipeline, meaning work is getting completed throughout the entire 2 week period, not just at the end.
- Each pipeline stays relatively the same width throughout the entire duration. This means you're moving work between pipelines at a steady pace. No one pipeline is growing (becoming a bottle neck) while others are shrinking.
- The Sprint backlog doesn't grow, which means you're protecting committed to work from interruptions mid-Sprint. This also could mean you have strong backlog management and refinement processes, ensuring work is properly prioritized sprint-over-sprint.