“Burndown Chart Template: Columns, Example and Step-by-Step Guide”

What columns does a burndown chart template need?

Eight, and the order matters less than the discipline of filling them at the same time each day. The table below is the schema I recommend for a two-week sprint, with a real value from the worked example further down.

Two details turn this from a table into a tool. The first is that column D records work crossing the definition of done, not work that is “nearly there”. If a task sits in review for three days, it stays in the remaining total, which is correct: from the sprint’s point of view the value has not been delivered. The second is that column E is signed and never edited later. A scope change you erase is a scope change you will repeat.

Day zero is not a row. Add a header cell for committed points and one for working days, because both formulas reference them, and locking them in named ranges prevents the most common spreadsheet failure: a copied formula that quietly points at the wrong total.

Which formulas make the template update itself?

Three formulas, and they are short enough to audit in a meeting. Set up named ranges first: TotalPoints, WorkDays, and BurnRate.

Burn rate is simply committed work divided by working days. A 62-point sprint over 10 working days burns 6.2 points per day.

For the ideal line, in the first data row (day 1), use:

`C5: =MAX(0,TotalPoints-A5*BurnRate)`

That returns 55.8 for day 1 of a 62-point sprint, 49.6 on day 2, and reaches zero exactly on day 10. The MAX wrapper stops the line from going negative if someone extends the template by accident.

For the actual line, day 1 is a special case because there is no previous row:

`F5: =TotalPoints-D5+E5`

and every row below it references the row above:

`F6: =F5-D6+E6`

Variance is the difference, and the only ambiguity is sign convention. Pick one and write it in the header, because half the arguments about burndown charts are arguments about which direction is good. I use actual minus ideal, so positive means behind schedule.

`G5: =F5-C5`

Two optional columns earn their space once the basics work. A projected finish date:

`=A5+ROUNDUP(F5/AVERAGE($D$5:D5),0)`

and a rolling average of completed points, which is the honest version of velocity, because it weights the good days and the bad ones equally over the window you choose.

`=AVERAGE(D5:D9)`

Do not add a percentage-complete column. It duplicates the actual line, and in practice percentages get estimated while points get counted.

What does a real two-week sprint look like?

Here is the full worked example. The team commits to 62 points for a 10-working-day sprint, so the ideal burn is 6.2 points per day. On day 4 the product owner adds a 10-point compliance item that cannot wait. The rest is the ordinary texture of a sprint: two slow days, one very good day, and a hard finish.

What the table says, in order:

• Days 1 to 3 are unremarkable. The team is 1.4 to 2.2 points behind, which is inside the noise of estimation error and does not justify a conversation.
• Day 4 is the story. The actual line moves up by 10 points while the ideal line keeps descending, so the gap jumps from 1.6 to 12.8. Nobody needs to be told the sprint is now at risk; the chart says it in one glance.
• Days 5 to 7 stay around 12 points behind. The team is working, but at roughly the committed pace, which is not enough to absorb 10 extra points.
• Days 8 to 10 deliver 32 of the 72 total points. That is 10.7 points per day, 73% above the sprint’s planned burn rate.

The last observation is the one worth carrying into the retrospective. Finishing on the last day looks like success on the chart, and it usually is not. A team that has to run at 173% of its planned pace for three days has found a reserve it cannot call on every sprint, and the chart showed the cost in advance.

The projection formula is what makes the chart actionable during the sprint rather than after it. At the end of day 5, remaining work is 43 points and the average daily completion so far is 5.8 points, so the projection is 43 divided by 5.8, or 7.4 days, rounded to 8. Day 5 plus 8 is day 13, three working days past the sprint boundary. That is a conversation on Friday afternoon, not a surprise at the review.

How do you read the line without overreacting?

Shape first, then numbers. A single high variance is almost always noise; a pattern across three days is information. The table below is the decoder I use in sprint reviews.

The flat-line case deserves emphasis because it is misread most often. A horizontal actual line means net change is zero: work completed equals work added. Teams sometimes announce that they are “on track” because the line is stable, when a stable line mid-sprint usually means the team is finishing work at exactly the rate new work arrives, which is the signature of a team that cannot reduce its queue.

The other misread is the heroic finish. If the chart only reaches zero in the final hours, the sprint was not well planned, it was rescued. Rescue is fine occasionally. Rescue every sprint is a planning failure disguised as commitment.

Should you burn down points, hours, or task counts?

Points for product work, hours for contracted or support work, task counts only for small teams with uniform task sizes. The unit should match what you actually estimate, because the chart’s value comes from comparing plan to reality in the same currency.

Story points are relative and deliberately abstract, which makes them good for forecasting and bad for external reporting. If a stakeholder asks “how many hours left”, points cannot answer without a conversion you will regret inventing. Hours are concrete and easy to explain, but they decay: a team that logs hours badly produces a chart that looks accurate and is not.

Task counts are the weakest option, and the reason is visible in the arithmetic. A sprint of 30 tasks looks healthy when 20 are closed, even if the 10 remaining tasks are the entire integration. Counting tasks assumes equal size, and almost no backlog satisfies that assumption for long.

There is a fourth option worth knowing: burn-up. Instead of plotting work remaining downward, a burn-up plots completed work upward against a rising scope line. It makes scope growth explicit instead of showing it as a bump in the remaining line, which is why regulated and client-facing teams often prefer it. The columns are the same; the chart is inverted.

What about scope changes and mid-sprint additions?

Record them, signed, on the day they happen, and never retroactively smooth the line. A scope change is not a failure of the chart; it is the chart doing its job.

There are only four honest responses to a 10-point addition in a 62-point sprint, and all four are decisions rather than hopes:

1. De-scope something of comparable size, and record both changes. The remaining line stays flat instead of jumping.
2. Extend the sprint, and move the ideal line’s end date so the benchmark stays truthful.
3. Accept and record, which is legitimate when the item is genuinely urgent. The chart will show a harder finish, and the retrospective will show why.
4. Split the item so part of it lands this sprint, and carry the rest explicitly.

What teams actually do is a fifth thing: add the work, keep the plan, and let the last three days absorb it. That works once. It also teaches everyone that the commitment is fictional, which is how burndown charts become decoration.

One practical rule keeps this clean. Any change above 5% of committed points needs a named decision-maker and a line in column H. Ten points in a 62-point sprint is 16%, well above the threshold, so the day-4 entry should carry a name and a reason, not just a number.

How does capacity maths keep the template honest?

Before the sprint starts, check that the commitment fits the actual available hours, because a burndown chart cannot fix an impossible plan. It will simply document the impossibility for ten days.

Take four developers, six productive hours each per day after meetings and support, and ten working days. That is 240 hours of capacity. If the team’s recent history says one story point costs about 3.5 hours of work, capacity is roughly 68 points. Committing to 62 points uses 91% of capacity, which leaves almost nothing for the unplanned question that always arrives on day 3.

The same calculation explains a common pattern: teams that commit to 100% of theoretical capacity produce charts that look fine for a week and then fall off a cliff. The cliff is not a motivation problem. It is arithmetic arriving on schedule.

Run the check with last sprint’s actual hours per point, not with an aspirational number. If the figure is not available, use the last three sprints’ completed points as a velocity range and commit to the low end for the first two iterations.

How do you build it in a spreadsheet in 15 minutes?

Five steps, no macros, no template marketplace.

1. Create a sheet with the eight columns above, ten rows for a two-week sprint, and two header cells for committed points and working days.
2. Fill column B with real dates and column A with 1 to 10. Skip weekends, or keep them and let the ideal line flatten across them.
3. Enter the burn rate formula once, name the range, then paste the ideal formula down the column.
4. Enter day 1’s actual manually, then paste the carry-forward formula for days 2 to 10.
5. Select columns A, C and F and insert a line chart with markers. Label the vertical axis with the unit, and put the sprint name and dates in the title.

Two formatting choices make the chart readable in a meeting. Set the vertical axis to start at zero, because a truncated axis exaggerates small variances into emergencies. And colour the actual line one colour for the whole sprint, with a single marker on today, rather than a gradient that implies a trend the data does not support.

If the team updates the sheet daily, the chart is current. If it is updated weekly, the chart is a report, and a report does not need a daily column at all.

What are the most common mistakes?

Six, and they repeat across teams.

• Ideal line drawn from yesterday’s remaining work. This hides scope creep by re-baselining the benchmark each day. The ideal line starts once, at planning.
• Updating completed work instead of remaining work. Remaining work is the honest number, because it forces someone to say what is left rather than what was done.
• Counting review as done. It inflates the burn and produces a sprint that ends at zero with three items still in review.
• Letting the chart become a performance review. Teams that are punished for a flat line start back-filling it, and then you have lost the signal entirely.
• Mixing units mid-sprint. Points on Monday and hours on Thursday produces a line that means nothing.
• Charting a Kanban team. Burndown assumes a fixed end date. Continuous flow has no such boundary, so the chart will trend to zero only when the queue empties, which may be never.

The performance-review point is the one that decides whether the template survives. A burndown chart is a diagnostic instrument. The moment it becomes a scoreboard for individuals, the data quality collapses, and a chart built on optimistic updates is worse than no chart, because it is confidently wrong.

When is a burndown chart the wrong tool?

When the team does not have a fixed iteration, when work arrives continuously, or when the real constraint is not time. In those cases the chart will be accurate and useless.

Support teams, for example, rarely control their intake. A burndown chart for a support queue shows a line that oscillates with customer behaviour, which tells you nothing about the team’s performance. A cumulative flow diagram, which plots the count of items in each state over time, exposes the actual constraint: a growing “waiting on customer” band is a different problem from a growing “in progress” band, and the burndown chart cannot distinguish them.

The second wrong use is executive reporting. A burndown chart is a team instrument at team resolution. Projected onto a portfolio slide, it invites questions the chart was never designed to answer, and it tends to be replaced by a percentage that is easier to read and less true.

Use burndown when the question is “will we finish this fixed batch of work by this date”. Use something else when the question is “where is work piling up”.

How does Doitify handle burndown without a spreadsheet?

Doitify is our product, so read this as disclosure. Sprints and backlogs are native: work items carry estimates, belong to a sprint with start and end dates, and move through statuses that you define. Because the plan and the status changes live in the same system, remaining work is a query rather than a manual entry.

The practical difference is the daily update. In a spreadsheet, someone has to remember to type the number. When the board is the source of truth, closing an item changes the remaining total immediately, which removes the single most common failure mode of the template: a chart that is accurate on Monday and fiction by Thursday. Gantt charts, roadmaps and workload views sit alongside, so the same estimates feed capacity planning without a second data entry.

That said, a spreadsheet is the right answer for a team running one sprint with no tooling. The template above works because the formulas are simple, and the discipline of a daily two-minute update is worth more than any feature.

Conclusion

A burndown chart template is not a design problem. Eight columns, two formulas, one daily update, and a chart with two lines. The teams that get value from it are the ones that treat the gap as a question to investigate rather than a verdict to defend.

Start with the schema, copy the formulas, and run one sprint. If the chart is updated daily and the retro discusses the shape rather than the final number, keep it. If it is being filled in on Friday afternoon, delete it, because a chart that describes last week is just another status report with extra steps.

If this post on burndown chart template was helpful, you might also enjoy Best Project Management Software for Client Work in 2026 and Free Daily Work Report Template (2026).