Burndown Chart Calculator
From total work, total days and elapsed days, compute the ideal burndown rate and ideal remaining work for an Agile project.
Input Data
Results
At a glance:The Burndown Chart Calculator works out, from total work, total days and elapsed days, how much work an Agile project should have left at a given point at ideal pace, for comparison with actual progress. It assumes steady consumption: ideal burn rate = total work ÷ total days; ideal remaining work = total work × (1 − elapsed days ÷ total days). Joining each day's ideal remaining gives the downward ideal line; plotting actual remaining on top shows health — actual above ideal = behind, below = ahead. It is a communication and review aid, not an individual appraisal tool.
Formula
Ideal burn rate = Total work ÷ Total days.
Ideal remaining work = Total work × (1 − Elapsed days ÷ Total days).
$$BurnRate = \\dfrac{TotalWork}{TotalDays}$$$$IdealRemaining = TotalWork \\times \\left(1 - \\dfrac{Elapsed}{TotalDays}\\right)$$How to Use
- Enter the total work and total days for the sprint or project.
- Enter the elapsed working days so far.
- View the ideal daily burn rate and the work that should remain now.
At 100 story points and 10 total days, ideal remaining work per day (ideal line)
| Elapsed day | Ideal remaining (points) | Ideal burn rate (pts/day) |
|---|---|---|
| Day 0 (start) | 100.00 | 10.00 |
| Day 2 | 80.00 | 10.00 |
| Day 4 | 60.00 | 10.00 |
| Day 7 | 30.00 | 10.00 |
| Day 10 (end) | 0.00 | 10.00 |
The ideal line is a fixed-slope straight line: 10 points burned per day. If on day 7 the team actually has 45 points left (> ideal 30), it is behind; 20 left means ahead. Illustrated at 100 points / 10 days.
Case Studies
Case 1: How much should remain mid-sprint
A Scrum team's sprint is 100 story points over 10 days. At day 4 the product owner wants 'at ideal pace, how much should remain now' to compare with actual.
Ideal burn rate = 100 ÷ 10 = 10 points/day; ideal remaining = 100 × (1 − 4/10) = 100 × 0.6 = 60 points.
So if all on plan, day 4 should leave 60 points. If the team actually has 75 (above ideal), it is behind — discuss blockers in stand-up; 50 means ahead.
Case 2: Actual line not straight — how to read it
Same sprint: actual burndown is rarely a perfect line. Suppose first 3 days barely moved (stuck on setup and dependencies), day 4 leaves 88 (far above ideal 60); but days 5–7 finished several tasks, day 7 drops to 25 (below ideal 30).
The point is not 'did any single day match the ideal' but the trend: though it started behind, mid-sprint acceleration recovered even ahead — healthy. Conversely, if the actual line stays flat and near deadline still hangs above ideal, that is the real warning (may not finish, consider scope cut). Practice notes: (1) actual line fluctuates from dependencies, discrete completion and scope change (added work bumps remaining up) — normal; (2) burndown shows quantity, not quality/difficulty; (3) never use it to appraise individuals or the team will under/over-estimate and hide problems. Pair with our EVM calculator for cost+progress and EMV for risk. Educational estimate only.
FAQ
What are the 'ideal line' and 'actual line' for?
The core value of a burndown chart is putting the ideal line and actual line side by side so progress is obvious at a glance. The ideal line is a straight line assuming steady consumption — from top-left (all work pending) to bottom-right (zero at end), showing 'if we finish on plan, how much should remain now'. This calculator gives that ideal value for any day. The actual line is the team's daily record of true remaining work. Overlap them: actual above ideal = consuming slower, behind; below = ahead; tracking = on time. This visualisation lets the team spot problems mid-sprint (no progress for days, or lots left near the end) and adjust early, instead of discovering at the end they cannot finish. It is a tool to communicate progress and trigger discussion.
Why is actual progress rarely a straight line?
The ideal line is straight because of the steady-consumption simplification, but real burndown is almost never a perfect line — that is normal. Reasons: (1) tasks have dependencies and order, some wait for predecessors, so slow start then acceleration; (2) completion is discrete — a big task finishes after several days, then remaining drops at once, looking 'stuck' meanwhile; (3) early sprint has planning and setup that may not immediately reduce points; (4) scope may change mid-way, adding work so remaining rises; (5) estimates are imperfect. So don't demand the actual line match the ideal — watch the trend and deviation: sustained, clear lag? Lots unfinished near deadline? Those are the signals to act on.
Can burndown be used to appraise the team or individuals?
Strongly discouraged. The burndown chart is meant to help the team self-review and collaborate transparently, not to pressure or blame. Once used for appraisal, members get defensive and game it: under/over-estimating work to look good, hiding difficulties, slicing tasks finely to fake activity, or avoiding honest recording. That distorts the chart and destroys its early-warning value. Healthy use: treat it as a team-owned radar to trigger constructive discussion (why behind? what blocks? what help?), not 'whose fault'. Appraise with broader, outcome- and growth-oriented methods, not one progress chart.
Burndown vs burnup — which to use?
Burndown and burnup are the two most common Agile progress charts, opposite in direction, each with strengths. Burndown (this calculator) tracks remaining work, line falling from high to zero — intuitive 'how much left, how far from done', good for daily single-sprint tracking. Its blind spot: when scope changes (add/remove mid-way), remaining rises, showing an upward bump, but you cannot tell from that one line whether the team was slow or scope grew. Burnup fixes this with two lines: completed work (rising from zero) and total scope (scope line). Scope change shows as the scope line moving up while completed keeps climbing — clear and unconfused. Choice: (1) stable scope, simple single-sprint remaining → burndown; (2) frequent scope change or you must show 'scope creep' to stakeholders → burnup is more transparent; (3) many teams use both — burndown for sprint daily, burnup for version/project scope and progress. No absolute better; know each blind spot and pick the honest one. Educational estimate only.
Why not demand the actual line match ideal, and when is real warning needed?
Many teams (especially management) mistakenly think actual should hug the ideal line and panic at any deviation. But that misuses the chart — the ideal is a mathematically steady baseline and real development is almost never steady; deviation is normal, not abnormal. Why actual is never straight: dependencies slow the start; discrete completion looks stuck; early setup; scope change bumps it up; estimates vary. So what truly warrants alarm? Watch signals, not single-point deviation: (1) sustained and widening lag — actual stays above ideal and pulls further away for days, suggesting systematic under-delivery, over-optimistic estimates, unresolved blockers or silent scope growth; (2) still high near deadline — at late sprint (day 8–9) actual remaining far above ideal is a strong 'may not finish' warning, decide scope cut or delay early; (3) long flat stretch — remaining unmoved for days means stuck on a blocker (waiting, hard tech, pulled resources), raise it in stand-up now; (4) sudden big drop only at the end — tasks too big or verification/testing pushed to last, high risk. Conversely, 'start behind, recover mid' or 'up and down but overall trending down to zero' are healthy. Right mindset: use burndown as a radar to trigger discussion, watch trend, slope andcritical point, not a ruler measuring fit to the ideal. Over-fitting pushes the team to manipulate numbers and loses the chart's honesty. Educational estimate only.
Related Tools
References
Content review: Calculatorism Finance Team. Results are for reference only; please refer to the relevant authorities for the official figures.