Agile teams generate a lot of data, but not all of it is useful, and some of it gets actively misused. Velocity, burndown charts, and cycle time are the three metrics that show up most often in Scrum and Kanban environments. Understanding what each one measures, and what it doesn’t, is the difference between using metrics to improve a team and using them to accidentally punish one.
Velocity: How Much a Team Typically Completes
Velocity measures the amount of work, usually in story points, a Scrum team completes in a sprint. Over several sprints, this number stabilizes into a rough average that helps with forecasting: if a team averages 30 points per sprint, a 300-point backlog will take roughly ten sprints, all else being equal.
The most important thing to understand about velocity is that it’s a planning tool, not a performance score. Velocity is specific to one team’s estimation habits and can’t be meaningfully compared across teams. A team that “increases velocity” by inflating story point estimates hasn’t actually gotten faster, and treating velocity as a target instead of a forecasting input is one of the most common ways organizations quietly poison their own data.
Burndown Charts: Tracking Progress Within a Sprint
A burndown chart plots remaining work (in points or hours) against time remaining in the sprint. In a healthy sprint, the line trends down toward zero as the sprint progresses. A flat line for several days, or a line trending upward, is an early warning sign, whether that’s scope creep, an underestimated task, or a blocker the team hasn’t surfaced yet.
Burndown charts are most useful as a daily conversation starter, not a report generated for management. The team checking its own burndown at stand-up catches problems days before a sprint review would.
Cycle Time: How Long Work Actually Takes to Finish
Cycle time, more common in Kanban environments but useful anywhere, measures the time from when work starts to when it’s actually done. Unlike velocity, cycle time works at the level of an individual work item and doesn’t depend on estimation accuracy at all, which makes it harder to game and easier to trust.
A team watching cycle time trend upward over several weeks has a concrete, early signal that something in the workflow, whether it’s review bottlenecks, unclear requirements, or too much work in progress, needs attention before it shows up as missed deadlines.
Using These Metrics Without Misusing Them
- Track trends over time, not single data points; one slow sprint isn’t a pattern
- Never compare velocity or cycle time across different teams
- Pair quantitative metrics with qualitative signals from retrospectives; a number rarely tells the whole story on its own
- Use metrics to start a conversation about the work, not to evaluate individual people
Metrics work best as a mirror the team holds up to itself, not as a report card handed down from outside. Teams that treat them that way tend to actually improve; teams that treat them as targets tend to just get better at hitting the number.
If your team is generating these metrics but isn’t sure what to do with them, that diagnostic work is a core part of what we cover in Agile Training and our onsite coaching engagements.