Read velocity, burndown and burnup charts and cycle-time data, and use them to forecast without turning them into targets.
Why it matters
Stakeholders always ask two questions: "Are we on track?" and "When will it be done?" Agile teams answer with simple measures drawn from their own history rather than guesses. Read well, these measures help a team spot trouble early and give honest forecasts. Read badly, or turned into targets, they mislead everyone.
Velocity
Velocity is the number of story points a Scrum team completes (to the Definition of Done) per sprint. Partly finished items count zero.
Sprint 1 2 3 4 5
Completed 18 23 21 24 23 average of last 3 = (21 + 24 + 23) / 3 = about 22.7
Uses:
- Sprint Planning: a rough guide to how much to take on.
- Release forecasting: 90 points left in the backlog / about 22 points per sprint = about 4 sprints. Give a range (for example 4 to 5 sprints), not a single date.
Limits: velocity is specific to one team and its own estimating, so never compare teams by velocity. If you make it a target, estimates quietly inflate and the number stops meaning anything. This is Goodhart's law: when a measure becomes a target, it ceases to be a good measure.
Burndown charts
A sprint burndown plots the work remaining (points or tasks) against the days of the sprint. A straight ideal line runs from the total at the start to zero on the last day.
Northside's 10-day sprint with 22 points:
Day 0 1 2 3 4 5 6 7 8 9 10
Ideal 22 20 18 15 13 11 9 7 4 2 0 (rounded)
Actual 22 22 20 20 19 17 14 11 8 5 2
How to read it:
- Above the ideal line: work remains that "should" be done by now. On day 5 the team has 17 points left against an ideal of 11: behind.
- Flat sections (days 0 to 1, 2 to 3): nothing finished. Often items are in progress but none is done yet, which is normal early on but a warning if it lasts.
- Steady steps down later: work is flowing.
- Ending above zero (2 points left on day 10): an item will not be done and returns to the backlog.
- Line going up: work was added during the sprint.
The useful question is never "why are you above the line?" but "what is blocking us, and does our Sprint Goal still look achievable?"
Burnup charts
A burnup chart shows two lines: total scope and work completed, both rising. Its advantage is that scope changes are visible. On a burndown, adding 10 points and finishing 10 points look like no progress; on a burnup you see the scope line jump and the done line climb. Burnups are popular for release tracking.
Flow metrics: cycle time, lead time, throughput
Kanban teams (and many Scrum teams) use flow metrics:
- Cycle time: time from when work starts on an item to when it is done.
- Lead time: time from when the item is requested (enters the backlog) to done. The customer feels lead time.
- Throughput: items finished per period (per week, per sprint).
- WIP: items started but not finished.
Definitions vary between teams and tools; agree exactly which board columns mark "start" and "done".
Reading cycle-time data
Here are ten finished items, with the day work started and the day each was done:
Item A B C D E F G H I J
Start 1 1 2 3 4 5 6 7 8 9
Done 3 6 4 10 7 8 9 15 11 12
Cycle 2 5 2 7 3 3 3 8 3 3 average = 39 / 10 = 3.9 days
Sorted: 2, 2, 3, 3, 3, 3, 3, 5, 7, 8. The average is 3.9 days, but averages hide the long tail. A better forecast for a customer is a percentile: "85% of our items finish within 7 days" (the 9th of 10 sorted values). That is a promise you can usually keep. A cycle-time scatterplot (one dot per item, done date on the x-axis, cycle time on the y-axis) shows the same data visually; dots far above the rest, like H at 8 days, are worth discussing in a retrospective.
Using metrics well
- Use them for the team's own learning and forecasting, not to rank people or teams.
- Look at trends, not single values.
- Combine with conversation: a chart tells you where to ask, not what the answer is.
- Forecast in ranges with percentiles or several sprints of velocity.
Common mistakes
- Velocity as a performance target, causing estimate inflation.
- Comparing velocity across teams.
- Counting partly done work in velocity.
- Reporting only averages for cycle time and making promises the long tail breaks.
Quick recap
- Velocity is completed points per sprint; use it to plan and forecast within one team.
- Burndowns show remaining work against an ideal line; burnups also show scope changes.
- Cycle time runs from start to done, lead time from request to done; throughput counts items finished.
- Forecast with percentiles and ranges, and never turn the measures into targets.
Try it
Open the Do tab. The program already calculates velocity, a burndown check and cycle-time statistics for Northside's data, except for one line. No programming experience needed.