Someone puts the cumulative flow diagram up on the screen at sprint review. The in-progress band has been quietly fattening for three weeks. The done band at the bottom went flat around the second one. Everybody in the room recognises the shape. Someone says the team needs to tighten up work in progress. Heads nod. The meeting moves on.

Nobody asks the question the people outside that room actually care about: what did those three weeks do to the release date we committed to?

What a cumulative flow diagram actually tells you

A CFD stacks the cumulative count of issues that have reached each workflow state, day by day, oldest state at the bottom. Read properly, it is a genuinely excellent diagnostic:

• The vertical height of a band is work in progress in that state.
• The slope of the bottom band is your departure rate — throughput, the rate work actually finishes.
• The slope of the top band is your arrival rate — how fast work is entering the system.
• The horizontal distance between two bands approximates cycle time through the states they enclose.
• A step change in the top band is a batch of scope landing.

Notice what every one of those readings has in common. Each is a rate or a count. None of them is a date. A cumulative flow diagram has no marker on its x-axis for the date the team committed to, and no way to express how far away that date now is.

All three killers show up on the chart. None of them get priced.

This is the frustrating part, because the CFD sees more than most teams give it credit for. Each of the three things that erode a release date leaves a mark:

Scope creep steps the top band upward. You can see the eleven issues that arrived last Thursday. What you cannot see is that they are worth nine days at 85% confidence — which is the only form in which that information is negotiable with a stakeholder.

Dependencies surfaced too late show up as a band that stops moving while the ones above it keep filling. The chart tells you work is piling up behind something. It does not tell you which blocking chain, whether it sits on the critical path, or how much slack has already been spent waiting.

Capacity changes are the slowest to appear and the most misread. Someone gets pulled onto a production incident in week two; the bottom band flattens in week four, because throughput is a trailing measure of a decision already made. By the time the CFD shows it, the days are gone.

Two snapshots, neither of them live

The confidence vote at PI planning was not the weak link. It was a room of experienced engineers putting expert judgment on the line against a plan they had just built, with the dependencies and risks in front of them. It was right on the day.

The CFD is the honest record of the assumptions behind that judgment drifting — throughput slower than the window it was voted on, scope larger than the baseline, work stuck where nobody expected. But it is still a picture of flow, not a picture of the commitment. You end up holding two snapshots side by side, doing the arithmetic between them in your head, in a meeting, under time pressure.

Turning the drift into days

Release Management, Roadmaps, Portfolio PPM & Timeline does not draw a cumulative flow diagram, and it does not replace the one you already read. It reads the same two facts out of Jira that your CFD is drawn from — completed throughput history and remaining scope in the Fix Version — and runs Monte Carlo simulation over them, continuously.

The output is not another chart to interpret. It is the committed date carried with its confidence: June 7 at 85%, on a 50/85/95% band the whole room can read. When the bottom band of your CFD flattens, the P85 date moves out and the confidence at the committed date drops that week, in days, while there is still room to pull scope back across the cut-line or resequence a dependency.

The team still owns the assumptions — which throughput window is representative, whose capacity is genuinely in, what is really in scope. The app does the arithmetic at Monte Carlo scale and keeps it current. A confidence vote is a snapshot; this is what keeps it live.

How to read the two together

1. Open the CFD to see whether flow changed, and in which state.
2. Open the release forecast to see what it cost — the gap in days between your committed date and the current P85.
3. Take that gap into the conversation before it becomes a slip.

If you want the mechanics, our docs cover how a CFD signal reaches the release forecast, including which inputs the app does and does not read. It is also worth pairing this with how to read a release burndown chart and our guide to work in progress, WIP limits and Little’s Law in Jira.

Your cumulative flow diagram is already telling you the truth about flow. It just cannot say it in the currency the business negotiates in. See the drift priced in days on your next Fix Version, free for 30 days. It Runs on Atlassian, so your Jira data never leaves Atlassian.

Rob Borges

Rob Borges spent the first half of his career hunting waste as a Lean Six Sigma Master Black Belt and wrangling portfolios as a PMI Portfolio Manager — until he realized the tidiest process on earth still can't out-plan an optimistic human. So he switched sides and became an Agile Coach. These days he helps Kanban, Scrum, and Agile-at-Scale teams trade gut-feel deadlines for flow data, turning "we'll probably ship sometime in Q3" into release dates leaders can actually take to the board. His rule of thumb: hope is not a forecast, but your throughput history usually is.

See Full Bio