Sprint review, slide four. The velocity chart. The last two green bars are noticeably shorter than the grey ones beside them. Someone says it was a rough couple of sprints: an incident, a holiday, a story bigger than it looked. Fair enough.

Then the release manager asks the question the chart can’t answer: are we still shipping on the date we committed to?

What a velocity chart actually tells you

For each completed sprint, a velocity chart shows the estimated work in the sprint when it started and the estimated work finished by the end. Across several sprints it tells you three useful things:

• Say versus do. The gap between the two bars is how far the sprint landed from its plan.
• Trend. Completed bars drifting down over time is pace falling.
• Stability. Big swings from sprint to sprint mean an average is hiding a lot.

Every one of those is a sprint quantity. The chart looks backward, one sprint at a time. A release lives across the next ten sprints, and the velocity chart has no place to put it.

The average-velocity shortcut

So teams do the arithmetic by hand. Remaining scope, divided by average velocity, equals a number of sprints. Count forward on the calendar and that is the date.

It is a reasonable first pass, but it assumes the remaining scope is fixed, the sprints in the average represent the sprints to come, and the people who produced that average will still be there next month. And it produces one date with no confidence attached, so nobody can tell a coin flip from a safe bet.

Those three assumptions are exactly the three things that erode a release date after the vote.

All three killers show up in the bars. None of them get priced.

Scope creep lands mid-sprint and stretches the gap between commitment and completed. The chart shows the gap, not that the eight issues added to the Fix Version this month are worth a week at 85% confidence.

Dependencies surfaced too late look like a sprint that simply underdelivered. The bar can’t say the work was blocked on another team, or that the blocking chain now sits on the release’s critical path.

Capacity changes are the slowest to show. Someone moves teams in week one; the bars shrink over the next two sprints, because velocity trails the decision. By the time the average moves, the days are gone.

The vote was right. The inputs moved.

None of this is a criticism of the team. The confidence vote at PI planning was expert engineering judgment, and it was right on the day. The velocity chart is the honest record of the inputs to that judgment changing afterwards; it just can’t re-price the commitment. So you hold two snapshots, a vote from six weeks ago and a bar chart from last Friday, and do the arithmetic between them in your head.

Turning the bars into days

Release Management, Roadmaps, Portfolio PPM & Timeline doesn’t draw a velocity chart and doesn’t replace the one you already use. It reads completed throughput history and remaining scope in the Fix Version from Jira, plus the capacity and dependency inputs you configure, and runs Monte Carlo simulation over them continuously.

The output is the committed date carried with its confidence: June 7 at 85%, on a 50/85/95% band. When pace drops or scope is added to the Fix Version, the P85 date moves out and confidence at the committed date falls, that week. When a capacity change is entered, the forecast reflects it without waiting two sprints for the green bars to catch up. You see the gap in days while there is still room to move scope, resequence a dependency or renegotiate.

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

Compare the committed date with the current P85 and take that gap into the conversation before it becomes a slip. For the mechanics, our docs explain how a velocity-chart signal reaches the release forecast, including what the app does and doesn’t read. It pairs well with reading a cumulative flow diagram against the committed date, burnup vs burndown charts at release level, and turning that drift into the one question your next sprint review should answer.

Your velocity chart already tells you the truth about last sprint. The committed date needs the next ten. See your velocity 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