The Budget Burn Chart Every CTO Should Have on One Screen
Last updated October 2026
An engineering budget burn chart puts three cumulative lines on one screen: planned spend, actual spend, and the dollar value of work actually finished. The gap between actual spend and finished work is your cost overrun, visible by sprint three or four. A chart that only compares spend to plan will hide it until launch.
Key takeaways
- Most burn charts compare money spent with money planned. That tells you whether you are spending on schedule, not whether the spending is buying anything.
- The line that matters is earned value: budget multiplied by the share of scope actually done. Plot it beside spend and the overrun shows up early.
- Two ratios summarize the screen: cost performance (earned value divided by actual cost) and schedule performance (earned value divided by planned value).
- The early read is reliable. Research on defense contracts and on software projects finds the cost index settles roughly 15 to 20 percent of the way in.
- Scope must be its own line. Added scope that never shows up on the chart is how a project looks 10 percent over budget while heading 60 percent over.
What is an engineering budget burn chart?
It is a cumulative chart of an engineering budget over the life of a release or a fiscal period. Finance tools draw one version of it: dollars planned versus dollars spent. Jira draws another: Atlassian’s documentation describes its burnup chart as a sprint’s completed work compared with its total scope, with no money on it at all.
Each view is half the picture. The finance chart cannot tell you that the team spent a third of the budget and finished a fifth of the work. The Jira chart cannot tell you what that fifth cost. The CTO version joins them on one set of axes, in dollars, so the question “are we going to come in on budget” has an answer you can read off the screen instead of a debate in the weekly review.
The method is not new. It is earned value management, the same arithmetic defense programs have used for decades, adapted to story points. Tamara Sulaiman’s AgileEVM write-up on InfoQ lays out the mapping: expected percent complete is sprints finished over sprints planned, actual percent complete is points finished over the current release total, and the release is re-baselined at every sprint boundary for points added or removed.
Which lines belong on an engineering budget burn chart?
Five lines and three numbers derived from them. Every line is cumulative and in dollars, except scope. If a line is not on this list, it belongs on a different screen.
| Element | How to calculate it | What it answers |
|---|---|---|
| Budget at completion (BAC) | Approved budget for the release or period, flat line | What did we commit to spend? |
| Planned value (PV) | BAC × (sprints completed ÷ sprints planned) | What should we have spent by now? |
| Actual cost (AC) | Loaded payroll, contractor and vendor invoices, plus tooling charged to the release | What have we actually spent? |
| Earned value (EV) | BAC × (points done ÷ current total points) | What is the finished work worth at plan prices? |
| Scope line | Total release points, re-baselined each sprint | Is the target moving? |
| Cost performance index (CPI) | EV ÷ AC | How much plan value does each dollar buy? |
| Schedule performance index (SPI) | EV ÷ PV | Are we finishing work as fast as planned? |
| Estimate at completion (EAC) | BAC ÷ CPI | Where will spend land if nothing changes? |
Two details decide whether the chart is trusted. First, actual cost has to be fully loaded. If contractor invoices arrive 45 days late, the actual cost line understates spend and flatters the CPI for a month and a half. Accrue them weekly from timesheets or pod rates instead of waiting for the invoice. Second, earned value has to use the current scope total, not the original one. That single choice is what makes scope creep show up as a cost problem instead of hiding inside “we are 25 percent done.”
What does an engineering budget burn chart show that a spend-versus-plan chart hides?
Here is a worked example. The numbers are illustrative, but the arithmetic is exactly what the chart does each sprint.
A release has a $360,000 budget, 12 two-week sprints, and 600 story points. After sprint 4 the team has finished 150 points and spent $132,000. During those four sprints, product added a net 60 points, so the release now totals 660.
- The spend-versus-plan view. Planned spend by sprint 4 is $120,000. Actual is $132,000. That is 36.7 percent of budget against 33.3 percent of time, about 10 percent ahead of plan. Most finance dashboards would show amber at worst.
- The work view. 150 of the original 600 points is 25 percent done. Against the real total of 660 points it is 22.7 percent.
- Earned value. $360,000 × 22.7 percent = $81,818 of finished work, at plan prices.
- The ratios. CPI is $81,818 ÷ $132,000 = 0.62. SPI is $81,818 ÷ $120,000 = 0.68.
- The forecast. EAC is $360,000 ÷ 0.62 = about $580,800. The release is not 10 percent over. It is on track to land about 61 percent over budget.
That last number is uncomfortable, and it is the reason the chart exists. A 61 percent forecast at sprint 4 leaves eight sprints to cut scope, add capacity, or reset the date with the board. The same news at sprint 10 leaves you a write-off.
How early can you trust a cost overrun forecast?
Earlier than most teams assume. The overrun in the example is not a sprint 4 fluke that will average out, and there is research on why.
In a 2010 PMI research paper on the time dependence of CPI and SPI for software projects, Richard Warburton cites U.S. Department of Defense acquisition data showing that cumulative CPI “does not significantly improve during the period of 15% through 85%” of contract performance, and tends to decline. His own model of software projects found the earned value cost forecast converged on the actual final cost about 15 to 20 percent of the way through, and on his calibration project it was within roughly 5 percent by week 10.
The practical reading: if CPI is below 0.85 a fifth of the way into a release, assume it stays there unless something structural changes. Hoping the team “speeds up once the foundation is in” is the most expensive belief in software budgeting.
The stakes are large. A McKinsey study with the University of Oxford of more than 5,400 IT projects found large ones, with initial budgets above $15 million, ran 45 percent over budget and 7 percent over time on average, while delivering 56 percent less value than predicted. Note the asymmetry: schedules slip a little, budgets slip a lot. A chart that tracks only dates will miss most of the damage.
What thresholds should trigger action?
These are suggested bands. They are a working convention, not an industry standard, so tune them to your own tolerance.
| CPI (cumulative) | Status | Action this week |
|---|---|---|
| 0.95 or higher | Green | No action. Check that scope is still re-baselined each sprint. |
| 0.85 to 0.94 | Amber | Find the cause: scope added, rework, blocked work, or staffing gaps. Report the EAC, not just the variance. |
| Below 0.85 | Red | Decide on scope cuts, capacity changes, or a revised budget. Tell the board now with the EAC in hand. |
Read CPI and SPI together. Low SPI with healthy CPI usually means the team is blocked or understaffed, not wasteful: work is cheap when it happens, it just is not happening. Low CPI with healthy SPI usually means rework, which in AI-assisted codebases often traces back to code that passed review and then failed under real load. Low on both is the pattern in the example, and it nearly always involves scope that grew faster than anyone recorded.
If you already track the leading indicators in our pillar on engineering delivery metrics that predict a missed deadline, this chart is where those indicators turn into dollars. It also pairs with how to budget an engineering team for the next 12 months: the budget sets BAC, and the burn chart tells you each sprint whether BAC still holds.
Why do engineering budget burn charts fail in practice?
The math is simple. The failures are in the inputs.
- Story points that drift. If the team re-estimates finished work upward, earned value inflates. Freeze points once a story is done, and watch for estimate inflation across releases. We cover why point totals make a poor productivity measure in velocity is not productivity; for EV they only need to be consistent within one release.
- Half-done work counted as done. Earned value should credit a story only when it meets the definition of done. Partial credit is how a team is “80 percent done” for six sprints.
- Costs that arrive late. Invoices, cloud bills, and AI tooling spend often land weeks after the work. Accrue them, or the CPI looks best right before it looks worst.
- Scope added outside the tracker. Work agreed in a meeting and never ticketed does not move the scope line, so it never shows up as overrun. It only shows up as a missed date.
- Nobody owns the screen. A chart reviewed monthly by finance and never by engineering is a report, not a control. Put it in the weekly engineering review, and give one person the job of explaining any CPI move larger than 0.05.
Frequently asked questions
What is an engineering budget burn chart?
A cumulative chart of an engineering budget that plots planned spend, actual spend, and earned value (budget multiplied by the share of scope finished) on one set of axes, with total scope as a separate line. The gap between actual spend and earned value is the cost overrun.
How do you calculate earned value for a software release?
Multiply the release budget by points finished divided by the current total points, re-baselined each sprint for scope added or removed. Cost performance index is earned value divided by actual cost; estimate at completion is budget divided by that index.
How early can a burn chart predict a cost overrun?
Fairly early. A 2010 PMI research paper on software projects found earned value cost forecasts converged on the actual final cost about 15 to 20 percent of the way through, and cited defense data showing cumulative CPI does not significantly improve between 15% and 85% complete.
How TopDevz keeps burn and delivery on the same screen
Our Delivery Pods start at $15K per month with 30-day notice, so the actual cost line is a known monthly figure rather than a pile of late invoices. Delivery is tracked through PULSE, which collects 400+ data points every week, so the earned value side of the chart comes from real completion data rather than a status meeting. The engineers behind those numbers average more than 10 years of experience, and TopDevz holds 96 percent team retention, which matters here because turnover is one of the quieter causes of a falling CPI.
Book a Code Review
If your CPI is sliding and nobody can say whether the cause is scope, staffing, or a codebase that keeps generating rework, a senior engineer can look at the code and the delivery data together and tell you which it is. Book a Code Review.