The burndown chart calculator above turns four numbers into the two facts a burndown chart is meant to convey: how much work is left compared with where the ideal line says it should be, and whether the current rate of progress will finish the sprint. It also handles the case most burndown discussions gloss over, which is scope changing after the sprint has started.
Arb Digital builds free tools that keep their scope narrow. This page is about a single sprint or iteration. The earned value calculator is the tool for cost and schedule variance across a whole project, with budgeted cost and actual cost in the picture; this one has no money in it at all, only work and days. Neither replaces the other, and using the project-level method on a two-week sprint tends to produce impressive-looking indices with very little signal.
What This Burndown Chart Calculator Does
A burndown chart plots work remaining on the vertical axis against time on the horizontal, with a straight reference line falling from the total at the start to zero at the end. The Agile Alliance's definition of the burndown chart describes it as an information radiator: something posted where everyone can see it, so that difficulties get confronted early rather than discovered late.
The calculator computes four things from that picture. Where the ideal line sits today. How far the actual remaining work is above or below it. What velocity the team has actually achieved, in points per working day. And what happens if that velocity continues: either a finish day inside the sprint, or a shortfall.
It also makes the scope question explicit. The same glossary entry notes the chart's main weakness, which is that it shows quantity completed without showing whether the backlog changed underneath. By separating committed points from points added or removed, and letting you choose which the ideal line is drawn from, the tool makes that movement visible rather than hiding it in a flattening curve.
How to Use It
- Enter the commitment and any change. Points added mid-sprint go in the second box, as a negative number if work was removed.
- Count working days, not calendar days. The sprint length and the days elapsed should both exclude weekends, holidays and any day the team had no capacity.
- Count only completed work. An item is done or it is not; crediting half of an unfinished story is what produces the cliff at the end of a sprint.
- Set the start date if you want a calendar answer. It is used only to convert a projected day number into a date, skipping weekends if you ask it to.
- Choose the ideal line's basis. Total scope answers whether the work will finish; the original commitment answers what the change cost you.
The Formula: How the Projection Is Made
Total scope is the commitment plus any change. Remaining work is total scope minus completed work. The ideal remaining on a given day is the chosen baseline multiplied by one minus the fraction of the sprint elapsed, so on a ten-day sprint at day four it is sixty per cent of the baseline. Variance is ideal remaining minus actual remaining, so a positive number means the team is below the line and therefore ahead.
Velocity is completed work divided by days elapsed. Days still needed is remaining work divided by that velocity, and the projected finish day is days elapsed plus days needed. The rate required to finish on time is instead remaining work divided by the days left, and comparing the two is usually more actionable than the finish date itself.
Work the defaults. Eighty points were committed and ten added, so total scope is ninety and thirty completed leaves sixty remaining. At day four of ten the ideal line is at ninety times 0.6, which is fifty-four, so sixty remaining is six points above the line: the team is behind. Velocity is thirty over four, or 7.5 points a day, so sixty remaining needs eight more days and the projection lands on day twelve of a ten-day sprint. Finishing on time would instead need sixty points in six days, a rate of ten a day, which is a third faster than the team has managed so far.
Why the Ideal Line Is Not a Target
The straight line assumes work completes at a constant rate, and almost nothing does. Real sprints start slowly while stories are picked up, complete in clusters as items reach done together, and often show a step rather than a slope. A team tracking above the line on day two and below it on day seven has not done anything wrong; it has simply finished things in a lumpy order.
Treating the line as a target rather than a reference produces two bad behaviours. The first is splitting stories artificially so that something can be marked done each day, which optimises the chart rather than the product. The second is counting partial progress, which converts the chart from a measure of finished work into a measure of effort spent, and effort spent has never predicted a delivery date.
What the line is genuinely good for is the size of the gap. Six points above the line on day four of ten is a conversation; six points above the line on day nine is a decision about what to drop. The same number means different things at different points in the sprint, which is exactly why the chart shows time on the horizontal axis rather than reporting a single percentage.
Scope Change, and the Chart That Flattens
The most misread burndown is the one that goes flat. It usually means one of two things, and they call for opposite responses. Either nothing is being completed, or work is being completed at a normal rate while new work arrives at the same rate. The line looks identical in both cases.
Separating the two is why this page asks for added points as a distinct input. With the ideal line drawn from the original commitment, a mid-sprint addition lifts the actual line away from the ideal and the gap is the cost of the change. With the line drawn from the total, the chart answers a different and equally legitimate question, which is whether the work now in the sprint can be finished.
The 2020 Scrum Guide is worth reading on this point, because it is notably restrained about tracking artefacts. It requires that progress toward the sprint goal be inspected, without mandating a burndown chart or any other specific instrument. A chart is one way of meeting that requirement, not the requirement itself.
What a Projection Can and Cannot Tell You
The projection here is a linear extrapolation of a small sample. On day one it is meaningless, on day two barely better, and it only becomes informative around the middle of the sprint when several days of real completion sit behind it. Reporting a confident finish date from two days of data is worse than reporting nothing.
It also assumes the remaining work resembles the completed work. If the easy items were done first, which is common, velocity will fall and the projection is optimistic. If the sprint began with a difficult spike that is now resolved, the reverse applies. Neither effect is visible in the arithmetic, and both are visible to the team, which is why the number is a prompt for a conversation rather than a substitute for one.
Finally, a projection past the end of the sprint is not a schedule. In a fixed-length iteration, work that does not finish returns to the backlog rather than extending the sprint, so the useful reading of day twelve on a ten-day sprint is that roughly two days of work will not be delivered, not that the sprint is now twelve days long.
How This Page Sits Beside the Other Planning Tools
The boundary in one sentence: this page tracks one iteration's remaining work against an ideal line, while the earned value calculator tracks a whole project's cost and schedule performance against a budget. Money appears in one and not the other.
For the calendar side, the business days calculator counts working days between dates and the time duration calculator handles elapsed time. The percentage calculator covers the variance arithmetic in isolation, the billable hours calculator converts effort into invoiced time, and the cyclomatic complexity calculator looks at the code the sprint produces rather than the schedule it ran to.
Arb Digital builds free tools like this one because useful pages earn attention. If you want tools, calculators or content built for your own audience, we can help.
See Our Web Design Work Talk to Arb DigitalCommon Mistakes to Avoid
- Counting partial progress — a burndown measures finished work, and crediting work in progress turns it into a measure of effort that predicts nothing.
- Using calendar days — weekends and holidays are not capacity, and including them flattens the ideal line into something no team can match.
- Hiding scope changes — a flat line caused by incoming work looks exactly like a flat line caused by no work, and only separating them tells you which you have.
- Projecting from two days of data — the extrapolation needs several completed days before it means anything, and an early projection is noise presented as a date.
- Treating the ideal line as a commitment — it is a reference for spotting a growing gap, not a daily quota to be hit by splitting stories.
Related Free Tools From Arb Digital
For project-level tracking with cost in the picture, use the earned value calculator. Count working days with the business days calculator, measure elapsed time with the time duration calculator, and handle the variance arithmetic with the percentage calculator. The billable hours calculator covers invoiced effort, the cyclomatic complexity calculator looks at the resulting code, and the full free online tools hub has everything else.
Frequently Asked Questions
It is a straight reference line falling from the total work at the start of the sprint to zero at the end. It assumes a constant completion rate, which real teams rarely achieve, so it is a reference for spotting a growing gap rather than a daily target.
Both conventions are used. Drawing it from total scope answers whether the work now in the sprint will finish. Drawing it from the original commitment leaves the added work visible as a gap, which shows what the change cost. This page lets you pick.
Earned value tracks a whole project against a budget, producing cost and schedule variances and performance indices in money terms. A burndown tracks one iteration's remaining work against time, with no cost in the calculation at all.
Because a burndown is a chart of work that meets the definition of done. Crediting work in progress makes the line fall smoothly while nothing is actually delivered, and the missing work then reappears as a cliff at the end of the sprint.
Either nothing is being completed, or work is being completed as fast as new work arrives. The two look identical on the chart and need opposite responses, which is why added scope is a separate input here.
It is a straight-line extrapolation from the days elapsed so far, so it is meaningless in the first day or two and becomes useful around the middle of the sprint. It also assumes the remaining work is like the finished work, which is often untrue.
No. The 2020 Scrum Guide requires that progress toward the sprint goal be inspected, but it does not mandate a burndown chart or any other particular artefact. A burndown is one common way of meeting that requirement.
In a fixed-length iteration it returns to the product backlog rather than extending the sprint. So a projection landing beyond the last day is best read as an estimate of how much will not be delivered, not as a longer sprint.
