Burndown analysis

Burndown analysis is the practice of plotting remaining work against time to show whether a team is on track to finish a sprint or release on schedule. The chart has two lines: an ideal line that falls steadily from the starting scope to zero on the deadline, and an actual line that traces the real work remaining each day. If a sprint starts with 50 story points over 10 days, the ideal line drops by 5 points a day. When the actual line sits above the ideal line, the team is behind.

The value of burndown analysis is that it surfaces a schedule problem days before the deadline, while there is still time to act. It also exposes patterns that a single status update hides, such as a flat line early in the sprint that suddenly drops at the end, which usually means work was not started, not that it was fast.

Burndown analysis is built from a daily reading of remaining work, but the most useful single number is the required burn rate: the amount of work the team must complete each remaining day to hit zero on time. Compare that to the actual burn rate the team has averaged so far, and the gap tells you whether the current pace is enough.

If 30 points remain with 5 days left, the required burn rate is 6 points a day. If the team has been averaging 4 points a day, the analysis says the sprint will overrun unless scope is cut or pace lifts. The inputs below are what you need to build and read the chart.

1. 1

   Total committed scope

   The story points or tasks the team agreed to at the start of the sprint. This sets where the ideal line begins.

2. 2

   Remaining work

   The open story points or tasks at each measurement, usually taken once per working day.

3. 3

   Days remaining

   Working days left until the deadline, excluding weekends and holidays the team does not work.

4. 4

   Actual burn rate

   Average work completed per day so far, used to project whether the remaining work will clear in time.

A burndown chart shows that the team is behind, but it does not say why. A metric tree decomposes the remaining-work trend into the forces that shape it, so a flat line or a stall points to a specific cause rather than a vague sense that the sprint is slipping. The remaining work sits at the top, and the drivers that push it up or pull it down sit beneath.

When the actual line drifts above the ideal, the tree lets you separate a scope problem from a throughput problem from an estimation problem. Added scope, blocked tasks, and optimistic estimates each move the line in similar ways but demand different responses.

Burndown does not have an absolute target, since a perfectly straight line is rare and not even desirable. The useful benchmark is how far the actual line sits from the ideal at the midpoint of the sprint, and whether the gap is closing or widening. The ranges below describe how to read the deviation between actual remaining work and the ideal line.

Improving burndown is about making the actual line track the ideal more closely, which means steadier flow, tighter scope, and honest estimates. A clean burndown is a symptom of a healthy process, not a goal to chase directly. The levers below target the branches that bend the line.

1. 1

   Ignoring scope changes

   Reading the line without noting added work makes a delivering team look stalled and a stalled team look fine.

2. 2

   Measuring completed work

   Plotting work done instead of work remaining hides the effect of new tasks pulled into the sprint.

3. 3

   Treating the last day as the only day

   A flat line followed by a late cliff is a warning, not a success. Steady daily progress is the goal.

4. 4

   Confusing burndown with productivity

   A team can hit zero by cutting corners. Read burndown alongside quality signals, not on its own.