Velocity, burndown, and burnup charts — what they actually measure

Velocity is the average number of story points a team completes per sprint, typically averaged over the last 3–5 sprints to smooth out normal variance. Its actual use is forecasting: a team with a stable velocity of ~25 points/sprint, looking at a 120-point body of upcoming work, can reasonably estimate "about 5 sprints" without needing to convert a single story into hours.

Velocity is meaningful only within one team, over time, using that team's own point scale — it is not comparable across teams (Team A's "5-point story" and Team B's "5-point story" reflect two different teams' independently-calibrated relative scales, not the same absolute size), and using it that way is exactly the misuse the earlier estimation lesson warned about.

A sprint burndown chart plots remaining story points (or task count) against the days left in the sprint, with an "ideal" reference line showing steady, even progress toward zero.

A burndown that's flat for the first several days, then drops sharply near the end, isn't automatically a red flag — work legitimately often completes in bursts rather than a smooth daily trickle, especially when a story needs to reach a specific milestone (passing review, clearing QA) before it counts as "burned down" at all. What is a genuine warning sign: a line that's flat and then rises — that means scope was added mid-sprint, which a standard burndown chart doesn't distinguish from "the team is just behind," even though those are two very different situations needing two very different responses.

This is the chart's real limitation. If a 30-point sprint has 10 points added mid-sprint (an urgent request, a story that turned out to hide another story inside it), a standard burndown just shows remaining work dropping more slowly than the ideal line — indistinguishable, on the chart alone, from "the team is simply underperforming." Both look identical: a line that isn't reaching zero on schedule. Without separately tracking scope changes, a team (or worse, a stakeholder glancing at the chart) can draw exactly the wrong conclusion about why the sprint is behind.

A burnup chart fixes this blind spot by plotting two lines instead of one: work completed (rising toward the total) and total scope (which can itself move, showing exactly when and how much scope changed).

If the total-scope line visibly steps upward partway through, that step is the scope change, made visible on the chart itself rather than left to be explained verbally after the fact — the team completed exactly as much work as the completed-line shows, and separately, the goalposts moved by exactly that much. This is why many teams, especially for anything longer than a single sprint (an epic, a release, a quarter), prefer burnup over burndown — it tells the truth about two different things (work done, and scope) that burndown collapses into one ambiguous line.

The actual value of both charts is the same as the cumulative flow diagram from the Kanban lesson: they're meant to prompt a specific, useful question, not deliver a verdict on their own. A burndown that's badly behind the ideal line should prompt "why — is this a scope problem, an estimation problem, or an execution problem?" not just "the team is failing." Treating either chart as a performance scoreboard, rather than a diagnostic starting point for a real conversation, produces the same corrosive incentive covered in the estimation lesson: people start managing the chart instead of the actual work, which makes the chart less honest and, ironically, less useful for exactly the forecasting purpose it exists for.