Velocity and burn-down charts are the two most widely used Agile delivery metrics — the instruments through which Scrum teams and project managers track sprint and release progress, forecast delivery dates, and identify performance trends. Despite their ubiquity, both metrics are frequently misused: velocity is treated as a performance target rather than a planning input, and burn-down charts are read as commitment trackers rather than problem-surfacing tools. Understanding what each metric actually measures, how to interpret it correctly, and what its limitations are is essential for any project manager working in Agile environments. This guide provides a clear, complete explanation of both.
Understanding Velocity
Velocity is the number of story points (or other effort units) that a Scrum team completes per sprint. It is measured at the sprint level — after the sprint review, the team counts the story points of all stories that fully meet the Definition of Done and records that number as the sprint velocity. Stories that are only partially complete do not count — partial completion is recorded as zero velocity for that story until it is fully done.
Velocity’s primary purpose is planning, not performance measurement. A team’s average velocity over multiple sprints provides a reliable basis for estimating how many story points the team can commit to in future sprints, and for forecasting when a given amount of remaining backlog will be completed. A team with a 6-sprint average velocity of 40 points can predict that a backlog of 160 points will take approximately 4 more sprints to complete — not as a commitment but as a probability-based forecast.
What Velocity Is Not
The most common and most damaging misuse of velocity is treating it as a performance metric that should be maximised or compared across teams. Teams under pressure to “increase velocity” inflate story point estimates to make the same work appear to produce more points — a practice that undermines the relative consistency that makes velocity useful as a planning tool. Teams with different estimation calibrations, different work type mixes, and different team sizes have incomparable velocities — comparing Team A’s 60-point velocity to Team B’s 45-point velocity tells you nothing meaningful about relative performance or capability. Velocity is a team-specific, internally consistent planning instrument; it is not a productivity benchmark.
Velocity Chart: The Long-Term View
A velocity chart displays the team’s story point completion for each sprint over time as a bar chart, with a rolling average line showing the trend. It provides three types of insight: current velocity (the most recent sprints’ performance), velocity stability (how consistent the team’s output is — high variance indicates unpredictable delivery), and velocity trend (whether the team is becoming faster, slower, or stable over time). A declining velocity trend sustained over multiple sprints is a delivery health warning — it typically signals accumulating technical debt, growing architectural complexity, key person loss, or sustained over-utilisation. An improving velocity trend signals capability development, improved processes, or reduced technical debt overhead.
Understanding Burn-Down Charts
A sprint burn-down chart tracks the remaining work in a sprint against the planned trajectory for completing all selected work by the sprint’s end. The y-axis represents remaining work (typically story points or story count), the x-axis represents sprint days, and there are two lines: the ideal burn-down (a straight diagonal line from total sprint commitment on day 1 to zero on the final day) and the actual burn-down (the daily updated line showing actual remaining work). Comparing actual to ideal reveals the sprint’s health in real time.
A burn-down that tracks close to the ideal line signals a well-executing sprint. A burn-down that starts flat for several days (work remaining doesn’t decrease) signals stories that are not being completed — possibly due to blocking impediments, over-estimation of team capacity, or stories that are larger than anticipated. A burn-down that drops sharply at the end suggests the team left most completion to the final days — a pattern that, while sometimes acceptable, signals sprint planning challenges when it recurs.
“Velocity is not a goal — it is a fact. Asking a team to increase their velocity is like asking a runner to run a faster time by measuring more frequently. Improvement comes from removing impediments and building capability, not from targeting the metric.” — Mike Cohn, Agile Estimating and Planning
Release Burn-Down: The Multi-Sprint View
A release burn-down chart extends the burn-down concept across multiple sprints to track remaining backlog against planned release. The y-axis shows remaining story points in the release backlog, the x-axis shows sprints, and there are two lines: the planned completion trajectory and the actual remaining backlog. A release burn-down also shows scope changes visually — when new stories are added, the remaining backlog line rises; when stories are removed or completed, it falls. The release burn-down makes the cumulative effect of scope creep visible in a way that sprint-level metrics cannot.
Velocity and Burn-Down Chart Reference
| Chart | Time Horizon | Primary Use | Key Warning Signal |
|---|---|---|---|
| Velocity chart | Multi-sprint | Capacity planning, release forecasting | Declining trend over 3+ sprints |
| Sprint burn-down | Single sprint | Sprint health monitoring | Flat line mid-sprint (no completions) |
| Release burn-down | Multi-sprint | Release date forecasting | Rising remaining work (scope creep) |
Key Takeaways
- Velocity is a planning instrument, not a performance metric — its purpose is to inform future sprint commitments and release forecasting, not to compare teams or measure productivity.
- Treating velocity as a performance target drives estimate inflation that destroys its planning utility — improvement should come from removing impediments and building capability, not targeting the metric.
- A declining velocity trend sustained over multiple sprints is a delivery health warning — investigate technical debt accumulation, key person changes, or sustained over-utilisation.
- Sprint burn-down charts surface sprint health in real time — a flat line mid-sprint signals stories not completing and requires immediate investigation of impediments or story sizing issues.
- Release burn-down charts make scope creep visible across multiple sprints — rising remaining backlog lines signal that scope additions are outpacing completion.
- Neither chart is a substitute for team conversation — both are conversation starters that surface questions; the team discussion that follows is what produces actionable improvement.
