← Insights

Operations

Sprint planning with a burndown that tells the truth

July 2026 · 6 min read

A sprint fails at the planning meeting far more often than it fails during the work. The team feels optimistic, the backlog is exciting, everyone wants to say yes, and by the time anyone does the arithmetic the sprint is already over-loaded by a third. Two weeks later it ends short, the leftover stories get quietly waved into the next sprint, and the team concludes it is "just bad at estimating". It usually is not. It took on more than it could ever have finished, and nothing in the room said so at the time.

You do not need Jira to run a disciplined sprint. You need two honest numbers - capacity and commitment - and a burndown that refuses to flatter you. All three fit comfortably in a spreadsheet.

Capacity versus commitment: the decision the sprint turns on

Capacity is how much the team can realistically do this sprint, in story points - based on how many points it actually completed in recent sprints, not how many it hoped to. Commitment is the sum of the points the team has pulled into the sprint. The entire health of a sprint lives in the gap between them.

The trap is that commitment grows silently. Each story looks small on its own. Nobody adds them up in the meeting, so the total creeps past capacity without anyone deciding it should. By the time the gap is obvious, the sprint is running and it is too late to say no gracefully.

The fix is to make the total impossible to ignore. Sum the committed points as stories go in, hold them against the capacity you set, and turn a flag red the instant commitment crosses the line. Now over-commitment is a decision you make with your eyes open - "we are at 115% of capacity, what comes out?" - not a discovery you make halfway through. That single flag prevents more failed sprints than any amount of mid-sprint heroics.

A burndown that does not lie

A burndown chart plots work remaining against time. It has two lines. The ideal line runs straight from the committed total down to zero across the sprint - a smooth, even descent, one steady slice of work burned down each day. The actual line is the real remaining work, plotted day by day as you update it.

The value is entirely in the gap between the two. When the actual line sits above the ideal, you are behind - and you can see it on day three, when you can still do something, not on day ten, when you cannot. A burndown drawn by hand at the end of the sprint tells you nothing you did not already know. A burndown updated daily is an early-warning system.

The honesty comes from a rule people find uncomfortable: a story only burns down when it is done. Not started, not "nearly there", not eighty percent - done. A line that lets partial credit through slopes reassuringly toward zero while the real work piles up at the end, which is the exact opposite of what a burndown is for. Let the ideal line compute itself so it is never fudged, plot the true remaining beside it, and the chart tells you the truth even when the truth is unwelcome.

Carry-over you count, not eyeball

Sprints rarely finish everything, and that is fine - what is not fine is losing track of what rolled over. When leftover stories are waved into the next sprint on a vague sense of "not much left", the next sprint inherits a hidden debt and starts already behind.

Count it instead. At the end of the sprint, tally the stories and points still not Done. That number is the honest starting weight of the next sprint, and it feeds straight back into the capacity conversation. A team that consistently carries over a third of its commitment is not unlucky; it is over-committing every sprint, and the carry-over count is the evidence that finally makes the pattern undeniable.

Enough agile for a small team

None of this requires ceremony you do not have time for. The loop is small:

• Set capacity from reality. Use what the team actually completed last sprint, not a stretch target dressed up as a plan.
• Pull stories until the flag warns you. Let the committed total climb toward capacity and stop when it says stop.
• Update remaining daily. One number a day keeps the burndown honest and turns a two-week gamble into a controlled run.
• Read the carry-over, then re-plan. Feed what rolled over into next sprint's capacity so the debt is visible, not inherited by accident.

A sprint is a promise about how much you will finish. Capacity says what the promise can safely be, the over-commit flag stops you breaking it before you start, and an honest burndown tells you day by day whether you are keeping it.

Agile at small scale is not about tooling. It is about being honest with two numbers and a chart - and the moment those three refuse to flatter you, sprint planning stops being wishful and starts being planning.