How to Explain Velocity and Burndown Charts to Stakeholders

Velocity and burndown charts are the core metrics Scrum teams use to understand their progress and predict capacity. But explaining them to stakeholders — especially non-technical managers, product owners from business backgrounds, or executives — requires translation. Many stakeholders want to treat velocity like a KPI or misread a burndown as a sign of failure. This guide gives you the vocabulary and communication strategies to explain these charts clearly and protect their meaning.

---

Understanding Velocity

What velocity measures

Velocity is the average amount of work a team completes in a sprint, measured in story points (or other effort units). It is calculated as:

$$\text{Velocity} = \text{Story points of completed items in a sprint}$$

A team that completes 32 story points in Sprint 1, 28 in Sprint 2, and 35 in Sprint 3 has a rolling average velocity of 31.7 points.

Velocity is used for:

• Forecasting — estimating how many sprints are needed to complete the remaining backlog
• Capacity planning — knowing how much work the team can predictably take into a sprint
• Trend analysis — spotting patterns over time (is the team accelerating, stable, or slowing?)

Velocity is NOT:

• A measure of productivity or individual performance
• A target to maximise
• A comparable figure across different teams (story points are relative within a team)

---

Key vocabulary for velocity conversations

Story points — a unit of relative effort estimation; 1 point ≠ 1 hour; they represent complexity, uncertainty, and effort combined Rolling average — velocity averaged over the last 3–5 sprints (more reliable than single-sprint velocity) Capacity — the available working hours in the sprint, influenced by team size, holidays, and meetings Throughput — the number of items completed per sprint (an alternative metric to story points) Forecast — a probability-based estimate of when work will be done, derived from velocity trends

---

Explaining Velocity to Stakeholders

The analogy approach

“Velocity is like the average speed of a car on a road trip. If you’ve been averaging 80 km/h for the last three hours, you can estimate when you’ll arrive. But you can’t force the car to go faster just because you want to arrive sooner — that would burn the engine. Velocity is there to help us plan realistically, not to pressure the team into working faster.”

---

When a stakeholder asks “Why can’t we increase velocity?”

“Velocity is an outcome, not a lever. If we inflate story point estimates to show higher velocity, the number goes up but the actual delivery rate stays the same. Real velocity improvement comes from removing impediments, improving team skill, and reducing external interruptions — not from pushing the team harder.”

---

When comparing velocity between teams

“Velocity isn’t comparable between teams — Team A’s story points and Team B’s story points are on different scales. It’s like comparing miles and kilometres. Each team calibrates their own scale. What matters is each team’s trend over time, not the raw number.”

---

Using velocity to forecast

“Our average velocity over the last three sprints is 30 points. Our remaining backlog has 120 points of work. That gives us a rough forecast of 4 sprints to completion — approximately 8 weeks. This assumes stable team composition and no major scope additions.”

---

Understanding Burndown Charts

What a burndown chart shows

A sprint burndown chart visualises the remaining work in a sprint over time.

• X-axis — time (sprint days)
• Y-axis — remaining story points (or hours, or items)
• Ideal burn line — a straight line from total sprint points on Day 1 to zero on the last day
• Actual burn line — the team’s real daily progress

A release burndown chart shows the same thing at the product level — remaining backlog versus time across multiple sprints.

---

Reading a burndown chart

Everything on the ideal line — the team is on track Actual line above the ideal — the team is behind; remaining work is decreasing slower than planned Actual line below the ideal — the team is ahead; work is being completed faster than planned Flat line / plateau — no work is being completed (impediment, integration issues, waiting for review) Step up (line goes higher) — scope was added mid-sprint (backlog items were added)

“On Day 6 you can see the burndown line plateaued for two days — that was when we discovered an external API dependency wasn’t available. The team couldn’t complete the integration stories until the vendor resolved their outage. Once unblocked, we recovered most of the lost time.”

---

Vocabulary for burndown conversations

Ideal line / ideal burn — the expected linear progress if work was distributed evenly Scope change — addition or removal of items mid-sprint (visible as an upward jump on the chart) Impediment — a blocker preventing the team from making progress Burndown — the rate at which remaining work is being completed Carry-over — incomplete sprint items moved to the next sprint Flat spot / plateau — a section of the burndown showing no progress Sprint scope — the total story points committed to a sprint Adjusted forecast — a revised completion estimate based on current burn rate vs. ideal

---

Common Stakeholder Misreadings

Misreading 1: A non-linear burndown means poor performance

Many stakeholders expect a perfectly straight burndown. Reality is always messier.

“A bumpy burndown chart is completely normal. Work rarely completes in a perfectly linear fashion — larger stories take longer to finish and then drop all at once. What matters is the overall trend: are we converging toward zero by end of sprint? In this case, yes.”

---

Misreading 2: Carrying over stories is always failure

“We carried two stories into next sprint. This wasn’t poor performance — it was late scope clarification that revealed the stories were larger than estimated. The team made good progress; the scope changed. We’ve updated our estimates and those stories are at the top of next sprint’s backlog.”

---

Misreading 3: A team that consistently finishes early should take more work

“The fact that the team finishes a little early is a healthy sign — it means we’re estimating conservatively and not over-committing. If we consistently pad the sprint with more work, we lose the buffer that allows the team to handle unexpected complexity. Some capacity for the unexpected is by design.”

---

Phrases for Reporting Velocity and Burndown

Situation	English phrase
Reporting stable velocity	“Our velocity has been stable between 28 and 33 points over the last five sprints — we’re in a good predictable range.”
Reporting a velocity drop	“We saw a velocity drop in Sprint 12 — the team lost two days to an unplanned outage response. This is a one-time event; we expect normal velocity to return next sprint.”
Explaining a troubled burndown	“The burndown shows a step up on Day 4 — the product owner added two stories mid-sprint after the discovery call with the client. Total scope increased by 8 points.”
Forecasting completion	“Based on current velocity, we forecast release by the end of Sprint 18. That’s our P50 estimate — there’s about a 20% chance of slipping one sprint if we hit significant unknowns.”
Defending against velocity pressure	“I’d caution against setting a velocity target. Velocity is a measurement tool, not a productivity target. Pressuring the team to increase it leads to estimate inflation and burnout — neither helps delivery.”

---

Practice

Master Agile metrics vocabulary with the Scrum and Agile Coach exercise set and explore more resources on the Scrum Master learning path.