Burndown chart calculator
With 100 story points in a 10-day sprint, the ideal line says 60 points should remain after day 4, falling by 10 a day. Enter total points, sprint length and days elapsed to get the full day-by-day guideline. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Total story points
- 100
- Sprint days
- 10
- Elapsed days
- 4
- Daily burn
- 10
- Remaining ideal
- 60
- Completed ideal
- 40
- Progress percent
- 40
A sprint burndown chart is the straight-line picture of how remaining story points should fall from the committed total to zero by the last day of the iteration. Scrum masters, product owners, and delivery managers use that ideal line as the baseline they draw actual remaining work against at the daily standup. This burndown chart calculator takes three numbers — total story points, sprint days, and elapsed days — and returns the ideal remaining work at the elapsed day plus the remaining ideal work for every day of the sprint. The identity is remaining of d equals total story points times one minus d over sprint days.
What the ideal burndown line is and how remaining work is formed
The ideal burndown line is a straight drop from the committed story-point total on day zero to zero remaining work on the last day of the sprint. That geometry is the definition every Scrum textbook and every backlog tool draws first: remaining work at day d equals total story points times one minus d divided by sprint days.
The slope of that line is the daily burn — total story points divided by sprint days — which is how many points the team would have to finish each day if progress were perfectly even. One hundred points over ten days is a daily burn of ten and remaining work of one hundred, ninety, eighty, and so on down to zero. Forty points over five days is a daily burn of eight.
A zero remaining count on the last day is the planned finish, not a surprise. A zero committed total is also legitimate: an empty sprint stays empty and every remaining value is zero. What is not legitimate is a sprint of zero days, because dividing by zero does not produce a slope, a daily burn, or a remaining series.
FAQ
What happens if sprint days is zero?
Ideal burndown is undefined when there are no sprint days to divide by, and the failure is not billed.
How many story points should the team finish each day?
Divide the committed total by the sprint length. That daily burn is what the team would finish each day if progress were perfectly even: 100 points over 10 days is 10 a day, and 40 points over 5 days is 8.
Can a sprint start with zero story points?
Yes. An empty sprint is a valid case: the ideal line stays flat at zero and every day shows zero remaining. Only a sprint of zero days is refused, because it has no slope.
What happens if the days elapsed go past the end of the sprint?
The ideal remaining work stays at zero after the last day instead of turning negative. Zero remaining on the final day is the planned finish of the sprint.
Does the burndown calculator track actual progress or predict the finish?
No. It draws only the ideal guideline from your three numbers. You plot the actual remaining work from your sprint board against it at the daily standup and judge the gap yourself.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/fin/burndown-chart \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"total_story_points":100,"sprint_days":10,"elapsed_days":4}'const res = await fetch("https://api.kit.forhosting.com/fin/burndown-chart", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"total_story_points": 100,
"sprint_days": 10,
"elapsed_days": 4
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/fin/burndown-chart",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"total_story_points": 100,
"sprint_days": 10,
"elapsed_days": 4
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/fin/burndown-chart", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"total_story_points":100,"sprint_days":10,"elapsed_days":4}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"total_story_points":100,"sprint_days":10,"elapsed_days":4}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/fin/burndown-chart", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"total_story_points": 100,
"sprint_days": 10,
"elapsed_days": 4
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "fin.burndown_chart",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Limits
max_sprint_days | 366 |
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
When sprint days is zero the slope is undefined, so the task fails with invalid_input and is not billed.
What the ideal burndown line is and how remaining work is formed
This endpoint does not ingest a Jira export, does not compare actual remaining work to the guideline, and does not forecast whether the team will finish. It prices and returns the textbook ideal line on three numbers you already have from the sprint board, the planning session, or a weekly status sheet.
Input contract, response shape, and error behaviour
POST a JSON body with three required finite numbers. total_story_points is the committed total at kickoff; aliases story_points, points, and total map to the same field so a board column can keep its name. sprint_days is the length of the iteration in days; aliases days, duration, and sprint are accepted. elapsed_days is how many days have already passed, zero at planning; aliases elapsed and elapsed_day are accepted. Each field may arrive as a JSON number or as a numeric string. Missing fields, empty strings, and non-finite values fail with invalid_input naming the field. If sprint_days is greater than three hundred sixty-six the request fails so the remaining-per-day series stays bounded. If total_story_points or elapsed_days is negative the request fails. Those failures are not billed. On success the body echoes the three inputs, then reports daily_burn, remaining_ideal at the elapsed day (clamped at zero after the last sprint day), completed_ideal as the complement, progress_percent as elapsed over sprint scaled to one hundred and capped at one hundred, days_remaining, remaining_per_day as a list of day and remaining pairs from day zero through the last sprint day, and a formula string restating the identity. Example: one hundred story points, ten sprint days, and four elapsed days yield daily_burn ten, remaining_ideal sixty, completed_ideal forty, progress_percent forty, and eleven remaining_per_day rows from one hundred down to zero. Pair the JSON with your own actual remaining series if you need the red line next to the guideline; this endpoint computes the ideal line only.
Where a burndown chart calculator earns its keep
Scrum masters use a burndown chart calculator when the board already shows committed points and calendar days and they need the same guideline their stand-up slide will print, without opening a project tool for a three-number identity. Failed validation does not consume balance. Program managers recompute remaining_ideal per squad so a portfolio review can compare how far each sprint should have burned by the same elapsed day with one shared rounding rule. Finance partners who staff delivery against story-point burn drop total_story_points, sprint_days, and elapsed_days from the planning sheet and pin remaining_ideal in a model that must not call a proprietary tracker API. This is a different search and a different job from computing velocity, cycle time, or earned value: those metrics need completed history or dollar weights, while an ideal burndown uses only the committed total, the sprint length, and how many days have elapsed. Keep sprint_days strictly positive, keep the committed total and elapsed days non-negative, pin the remaining_per_day series in tests, and you get a reproducible ideal burndown for dashboards, LMS plugins, and edge workers without standing up a project-tracking engine of your own.
Integration use cases
Daily standup guideline
Turn committed story points, sprint length, and days elapsed into the remaining_ideal number you put next to actual remaining work on the standup slide.
Multi-squad portfolio reviews
Recompute remaining_per_day per team from the same three inputs so every squad’s guideline shares one slope and one rounding rule.
Delivery staffing models
Pin remaining_ideal in a capacity sheet without calling a proprietary tracker for a linear identity you already have the inputs for.
Technical questions
How is the ideal burndown remaining work calculated?
Send finite numbers total_story_points, sprint_days, and elapsed_days. The API returns remaining(d) = total_story_points × (1 − d / sprint_days), plus daily_burn and remaining_per_day for every sprint day.
Does the calculator compare actual remaining work to the guideline?
No. It returns only the ideal line. Plot your board’s actual remaining series next to remaining_per_day if you need the red-versus-grey burndown picture.
What if more days have elapsed than the sprint length?
remaining_ideal and days_remaining clamp to zero, progress_percent is one hundred, and remaining_per_day still lists the guideline through the last sprint day.
What does the burndown chart calculator cost?
The browser tool is free. API requests use prepaid KIT balance at $0.002 per successful call; invalid input is not billed.