Velocity and Burndown: Reading the Numbers Without Fooling Yourself

Velocity does not measure what you think it does

Velocity adds up completed estimation points over a sprint. That's all. It measures neither the value delivered, nor the real difficulty, nor the quality. Two teams with the same velocity may have produced things with no relation to each other.

The most common mistake is to turn it into a goal. As soon as a velocity becomes a target, estimation starts serving the target: points get inflated, work gets split differently, questionable cards get closed. The number goes up, the information disappears.

A concrete example: a team of five people hovers around 42 points per sprint for six sprints. A new sprint is planned at 60 points because an executive "needs" to go faster. Predictable result: cards reviewed hastily, and a following sprint at 30 points. Velocity did not increase, it was shifted in time.

Three defensible uses

• Sizing the next sprint based on the average of the last three, not the best.
• Detecting drift: a velocity that drops 40% over two sprints deserves a conversation.
• Comparing a team to itself over time, never to another team.

A burndown that goes down proves nothing about what was delivered

The burndown displays the remaining work day after day. Its slope tells a trajectory, not a quality. A curve that plunges the day before the review can signal a real pace… or a massive closing of barely verified cards.

A 2026 article on cognitive debt describes precisely this phenomenon: an engineer who delivers seven features in one sprint can show impeccable metrics, and find themselves six months later unable to explain their own code. The author speaks of a gap between production speed and comprehension speed, invisible in velocity metrics, and which eventually shows up in later indicators such as mean time to recovery or change failure rate (rockoder.com).

In other words: a clean burndown can coexist with a real problem. The graph does not see it.

What to look at alongside

• The number of cards reopened after the sprint review.
• Time spent in code review, not just in development.
• The share of cards completed on the last day of the sprint.

Cumulative flow shows what velocity hides

The cumulative flow diagram stacks cards by state (to do, in progress, in review, done) over time. Its strength is making bottlenecks visible. A "in review" band that thickens week after week indicates that production is going faster than verification.

This imbalance has a cost. The article on cognitive debt puts it clearly: when a junior engineer can generate code faster than a senior engineer can seriously audit it, review depth drops, often without an explicit decision, because organizational pressure pushes toward throughput (rockoder.com).

Cumulative flow does not say why the band is growing. It says where to look. That is already a lot.

Four misinterpretations that come back all the time

1. Confusing capacity and commitment. Past velocity describes what was done, not what is promised.
2. Smoothing the numbers to reassure. Removing an atypical sprint because it "doesn't count" amounts to erasing the most useful information.
3. Using metrics for individual evaluation. As soon as a report is used to rank people, the data becomes a game.
4. Comparing teams to each other. Points are not a universal unit, even within the same organization.

A team that sets up a Kanban board with customizable columns and an activity log, for example in Ever Earlier, already has the raw material: who moved what, when, and how fast cards move through the columns. Reports add nothing if that base is not reliable.

Reading the numbers without turning them into a surveillance tool

The difference between a useful report and a surveillance tool comes down to three simple rules.

Rule 1: one number, one decision

Before opening a report, write down the question it must answer. "Is the sprint oversized?" "Where is pending work accumulating?" A graph that changes no decision does not need to be consulted every week.

Rule 2: look at trends, not points

A velocity of 38 points in an isolated sprint means nothing. Three sprints at 38, 40, 37 after an average of 45, yes. The burndown is read the same way: the shape of the curve matters more than its final value.

Rule 3: discuss causes, not scores

A cumulative flow that shows a review bottleneck opens a discussion about card size, reviewer availability, the definition of "done." It does not single anyone out.

In Ever Earlier, sprint reports (burndown, velocity, cumulative flow) are accessible from the same space as the backlog and user stories. The benefit is practical: when a story remains stuck in review, you find it directly in the board, with its comments and history, without switching tools.

Setting up a healthy reading in three sprints

No need for a major project. Three sprints are enough to establish a routine.

1. Sprint 1: measure without changing anything. Note the velocity, the shape of the burndown, the thickness of the cumulative flow bands. No conclusions.
2. Sprint 2: identify a single point of attention, for example cards completed on the last day. Talk about it in the retrospective, without a numerical goal.
3. Sprint 3: test a concrete adjustment — reduce the maximum card size, or block half a day for review mid-sprint — and see if the curve changes.

This pace avoids the classic pitfall: turning a retrospective into a performance committee. A retrospective that examines trends over three sprints produces decisions. A retrospective that comments on the week's number produces tension.

What to remember

Velocity describes past capacity. Burndown describes a trajectory. Cumulative flow describes a circulation. None of the three measures the quality, value, or comprehension of the work delivered.

Using them correctly means treating them as diagnostic instruments, not as grades. A gap between production and comprehension can remain invisible in these reports for months; that is a reason to read them with caution, not to abandon them.

If you want to test this reading on a real project, the Starter plan of Ever Earlier is free, without a credit card, with three projects and five members.