Burndown Chart Calculator
The burndown chart calculator translates sprint progress into the metrics a Scrum team needs for a practical planning conversation: current speed, required speed, remaining work, variance from the ideal line, and projected time left. It is intentionally about work remaining versus time, not cash burn. Enter the sprint duration in working days, total committed story points, elapsed working days, and story points burned. The form requires elapsed days not to exceed sprint duration and burned points not to exceed committed points.
Although a burndown chart is an agile delivery tool, it belongs in startup and business finance conversations because delivery timing creates financial consequences. A team that misses a release may delay revenue recognition, customer onboarding, renewals, billing milestones, or sales commitments. A team that burns down work predictably can plan contractor spend, support staffing, implementation dates, and marketing launches with more confidence. To connect delivery capacity with broader planning, compare this page with the business budget calculator, software contract value calculator, and salary calculator.
Inputs and workflow
Sprint duration is the total number of working days in the sprint. Use the working-day calendar the team actually plans around, not calendar days, if weekends or holidays are excluded. Total story points is the committed scope after sprint planning and any formal scope changes. Days elapsed is the number of working days completed so far. Story points burned is the amount of accepted or completed work.
The calculator does not draw a chart image. Instead, it gives the numbers behind the chart. If remaining work is greater than zero, the headline is the required burndown speed in points per day. If all committed points are burned, the headline becomes “Sprint work remaining” with a value of 0 pts. Current speed is always points burned divided by actual days elapsed, unless no days have elapsed, in which case the current speed is zero. This detail matters: on day zero, the form does not invent a pace.
Formula used by the calculator
The calculator first rejects elapsed days beyond sprint duration and burned points beyond total committed points. Within that valid domain, remaining work is direct subtraction:
Remaining days are also direct subtraction:
Current speed uses the entered elapsed days:
When days elapsed is zero, the calculator uses 0 instead of dividing by zero. Required speed is:
When no days remain while work remains, required pace is undefined and the calculator displays “No remaining sprint time.” No finite pace is presented as a result for that branch. The ideal line is:
Variance is:
Projected time left is:
If current speed is zero, projected time left displays “No current pace.”
Example
Use the default inputs: 10 sprint days, 35 total story points, 5 days elapsed, and 15 points burned. Elapsed days are within the sprint, so remaining days are 5. Remaining points are:
Current speed is:
Required speed is:
Ideal burned points are:
Variance is:
Projected time left is:
The form therefore shows a required burndown speed of 4.00 pts/day, current speed of 3.00 pts/day, 20.0 pts remaining, 2.5 pts behind the ideal line, and 6.7 days of projected time left. The note says 20.0 points remain across 5.0 working days.
How teams use the result
The calculator is most useful in daily planning, sprint review preparation, and capacity discussions. If required speed is higher than current speed, the team can look for blockers, clarify acceptance criteria, reduce scope, split a story, add review capacity, or adjust stakeholder expectations. If current speed is above required speed, the team may still need to check quality and remaining risk; a healthy burndown does not guarantee that the hardest stories are done.
Product managers can use the variance to make tradeoffs visible. A sprint that is behind the ideal line may still succeed if the remaining stories are small and unblocked. A sprint that is ahead may still be risky if the remaining work is integration-heavy. Finance and operations teams can also use the numbers to understand whether delivery commitments align with staffing costs, customer contract dates, and launch budgets. When delivery delays affect revenue timing, use the burn rate calculator to see whether extra development time changes runway.
Caveats and quality checks
A burndown chart is only as good as the team’s point system and completion rules. Changing story-point estimates during the sprint can make the trend hard to interpret unless the total point input is updated. Counting half-done work as burned makes the sprint appear healthier than it is. Using calendar days when the team plans with working days will understate required pace after weekends or holidays.
The straight-line ideal is a reference line, not a law of nature. Many teams finish stories in batches, so the chart may stay flat for several days and then drop sharply after review. That pattern is not automatically bad, but repeated late drops can reveal oversized stories or late testing. The calculator should prompt a conversation about flow, risk, and scope rather than become a scoreboard.
Method and source limits
Atlassian documentation establishes common burndown-chart semantics. This linear model assumes story points and working days are whole-number planning units, rejects elapsed days beyond sprint duration, and does not forecast scope changes. Sources and linked guidance below were accessed July 9, 2026; later revisions are outside this page version.
Sources
- Atlassian, Burndown charts — overview of burndown charts and agile project tracking.
- Atlassian, Sprints — Scrum sprint planning context and time-boxed iteration concepts.
- Atlassian Support, View and understand the burndown chart — practical interpretation of burndown chart changes.