Key Takeaways
- A token burndown chart plots the AI token budget remaining against the days of the Sprint, the same way a Sprint burndown plots work remaining.
- On its own it is dangerous: tokens spent are not progress. Always read it next to a verified-work line — Sprint Backlog items that meet the Definition of Done.
- Six patterns cover most of what the chart tells you, from a healthy steady burn to the costly “burn without progress” that signals retry loops or unclear items.
- The chart belongs to the Developers. Used as a cost-control stick, it pushes teams to skip verification — the exact opposite of what it is for.
In AI-augmented Sprint Planning, the team sets a token budget alongside the Sprint Goal. That budget is a forecast. And a forecast nobody inspects during the Sprint is just a guess the team will be surprised by on day eight.
The token burndown chart is the simplest way to inspect it. It borrows the shape every Scrum team already knows — a line falling from a budget toward zero across the Sprint — and applies it to the one resource agents consume that humans never did: metered machine capacity.
But there is a trap built into it, and most teams fall into it in their first Sprint. This guide shows you how to build the chart, how to read it, and how to keep it honest.
AI moves the constraint from generating work to verifying it. A chart that only shows how fast you are generating tells you about the part that is no longer the constraint. That is why a token burndown always travels with a verified-work line.
What Is a Token Burndown Chart?
A token burndown chart has two axes. The horizontal axis is the days of the Sprint. The vertical axis is the AI budget still available — in tokens, or in money once you use more than one model. Two lines sit on it:
- The ideal line: a straight diagonal from the full budget on day one to zero on the last day. It is a reference, not a target.
- The actual line: the budget genuinely left at the end of each day, pulled from your model provider's usage data or your LLM gateway.
One point of honesty before going further. The Scrum Guide does not require any burndown chart. It names burn-downs, burn-ups and cumulative flow as practices some teams find useful for forecasting, and is clear that none of them replaces empiricism. Treat the token burndown the same way: a complementary practice that gives transparency, not a new Scrum artifact.
Why the Sprint Burndown Alone Stops Working
The classic Sprint burndown tracks work remaining in the Sprint Backlog. With AI agents doing part of the work, that line starts to lie in two ways.
First, it collapses too fast. An agent can turn a stack of items into pull requests in an afternoon, so “remaining work” drops off a cliff. But generated is not done. The items are now sitting in a review queue, and the real remaining work — understanding, testing and accepting that code — has barely started.
Second, it ignores cost. Two teams can show identical Sprint burndowns while one spends three times as much on agents because of retry loops, oversized context windows, or items so vague the agent kept starting over. Unchecked, that spend becomes the next budget conversation with finance — usually after the money is gone.
The token burndown fixes the second problem. The verified-work line fixes the first. You need both.
The Two-Line Rule: Tokens Burnt vs Work Verified
Plot the token budget remaining (as a percentage) and the share of Sprint Backlog items that meet the Definition of Done (also as a percentage) on the same chart. The token line falls; the verified line rises. Where they sit relative to each other tells you more than either line alone.
Read the gap like this. If the token line is falling faster than the verified line is rising, agents are generating work faster than the team is accepting it. That is not productivity. That is verification debt accumulating in real time, and you are paying for it twice: once in tokens now, and again in rework later.
How to Build a Token Burndown Chart in Six Steps
1. Choose the unit
If the team uses a single model at a flat price, raw tokens are fine. Most teams don't. Input, output, cached and reasoning tokens are priced differently, and a heavy reasoning model can cost many times more per token than a light one. Once the model mix varies, burn down money (or a normalised cost unit) instead, so a day of cheap autocomplete and a day of expensive agent runs are comparable.
2. Set the budget in Sprint Planning
The starting point of the chart is the budget the Developers forecast when they create their plan. Base it on what similar work actually consumed in past Sprints, not on the vendor's tier limit. If you are still working out how to arrive at that number, the token budget planning guide on Scrum Day India covers the forecasting side in depth; this article is about what happens after the Sprint starts.
3. Hold back a reserve
Keep part of the budget outside the main burn — a starting point of 15–20% works for most teams new to this — for review agents, test generation and the rework that verification inevitably surfaces. Plot it as a horizontal band near the bottom of the chart. A team that eats into the reserve by day four has learned something important about its plan.
4. Tag every agent session with a Product Backlog item
This is the step that makes the chart useful rather than decorative. Route agent calls through a gateway or proxy, or use the tagging your provider supports, so each session carries the ID of the item it served. Without tags you can see that you are overspending. With tags you can see where.
5. Update it before the Daily Scrum
Automate a daily snapshot so the chart is current when the Developers meet. A chart updated weekly arrives after the decisions it should have informed.
6. Add the verified-work line
Count items that meet the Definition of Done — merged, tested, reviewed by a person who can explain the change. Not items with an open pull request. If your Definition of Done for AI-generated work is machine-verifiable, this line can be pulled automatically as well.
Reading the Chart: Six Patterns and What They Mean
After a few Sprints you will recognise the same shapes repeating. Each one is a question for the team, not a verdict.
| Pattern | What you see | What it usually means | What to inspect |
|---|---|---|---|
| Steady pair | Tokens fall close to the ideal; verified work rises steadily. | Agent output and human review are in balance. | Nothing urgent. Note the actual burn as a forecast input for next Sprint. |
| Cliff drop | A large share of the budget goes in the first two days. | Agents were pointed at everything at once. Review capacity cannot keep up. | The size of the review queue. Limit how many agent-generated items can wait for review at once. |
| Burn without progress | Tokens fall fast; the verified line stays flat. | Retry loops, oversized context, or an item too ambiguous for an agent to finish. | Spend per tagged item. One item eating a third of the budget is a refinement problem, not an agent problem. |
| Flat line | The token line barely moves for days. | Agents are blocked or idle — or people are using untracked personal tools. | Blockers, access issues, and whether the chart is still seeing all the spend. |
| Early empty tank | Budget hits zero before the end of the Sprint. | The forecast was wrong, scope grew, or the pattern above went unnoticed. | Whether the Sprint Goal is still achievable. Involve the Product Owner before adding budget. |
| Step up | The remaining line jumps upward mid-Sprint. | Budget was topped up. | That the top-up was a transparent team decision, recorded on the chart, with the reason stated. |
A Worked Example
A team of five Developers runs a ten-day Sprint with eight Product Backlog items and a token budget they forecast from the previous two Sprints. By the end of day three, 55% of the budget has gone and only one item meets the Definition of Done — the shape in the chart above.
At the Daily Scrum, the tags tell the story: a single item has consumed nearly a third of the whole budget. Its acceptance criteria said the export should “handle large files gracefully”, and the agent kept rewriting the streaming logic because it had no definition of large or of graceful.
The Developers stop the agent on that item, pair a person with it for half a day to pin down the limits, and hand a sharper brief back to the agent. Spend slows, the verified line starts to climb, and the team finishes seven of eight items. In the Retrospective, they agree on one change: an item doesn't go to an agent until its acceptance criteria contain numbers, not adjectives.
This example is a composite built to illustrate the pattern, not a single client engagement.
Using the Chart in Each Scrum Event
Sprint Planning. Last Sprint's actual burn is the best input for this Sprint's budget. Look at what the work cost, not what you hoped it would.
Daily Scrum. The Developers inspect progress toward the Sprint Goal. The chart is one input to that conversation — a glance, not an agenda item. The useful question is never “why did we spend so much?” but “is our spend moving us toward the Sprint Goal?”
Sprint Review. Stakeholders increasingly ask what AI is costing. Showing cost per verified item — not cost per generated item — turns that into a value conversation the Product Owner can lead.
Sprint Retrospective. Look at the trend across Sprints. Is the share of tokens spent on rework shrinking? Are the same kinds of items causing burn without progress? That is where the real improvements come from.
Who Owns the Token Burndown?
The Developers. The Sprint Backlog is theirs, the plan is theirs, and the token budget is part of that plan. They are the ones who can act on what the chart shows, so they are the ones who should keep it.
The Product Owner cares about the chart for a different reason: it makes the cost side of trade-offs visible. Whether an item is worth an expensive agent run, or better done by a person, is a value decision as much as a technical one. Product Owners who want to get sharper at those calls will find this covered in the AI Essentials for Product Owners (PSPO-AI) course.
The Scrum Master's job is to keep the chart healthy, and that mostly means preventing three misuses:
- Rewarding low burn. If spending less is praised, teams will quietly skip review agents, tests and verification — the cheapest way to save tokens and the most expensive way to ship.
- Comparing teams or individuals. Different products, codebases and model mixes make burn rates incomparable. A leaderboard turns a transparency tool into a surveillance tool.
- Treating the budget as a target. A budget that must be spent by Sprint end is a budget that will be spent, whether or not it helps.
Coaching a team through these is exactly the kind of work covered in the AI Essentials for Scrum Masters (PSM-AI) course.
Token Burndown vs Sprint Burndown vs Release Burndown
| Sprint burndown | Release burndown | Token burndown | |
|---|---|---|---|
| Tracks | Work remaining in the Sprint Backlog | Work remaining toward a release or the Product Goal | AI budget remaining in the Sprint |
| Time axis | Days of the Sprint | Sprints | Days of the Sprint |
| Answers | Are we on track for the Sprint Goal? | When might we reach the goal? | Is our machine capacity lasting, and where is it going? |
| Blind spot | Generated work looks finished before it is verified | Scope change hidden unless shown as a burn-up | Spend says nothing about value without a verified-work line |
| Used by | Developers | Product Owner and stakeholders | Developers, with the Product Owner for trade-offs |
If you need a longer horizon, the same idea scales up: a token burn-up across Sprints, plotted next to items delivered toward the Product Goal, shows whether AI spend is buying the outcome you are after. That is a topic for its own article in this series.
Start Small
You don't need a dashboard product to begin. A spreadsheet with a daily row — budget left, items verified — and a chart of both columns is enough for the first Sprint. Get the tagging right, keep the verified line next to the token line, and let the Developers own it. The chart will tell you within two Sprints whether your agents are adding capacity or just adding cost.
Product Owner? Learn to weigh agent cost against value, write items agents can finish without burning budget, and lead the cost conversation in Sprint Review.
Explore the PSPO-AI course →Frequently Asked Questions (FAQ)
What is a token burndown chart?
A token burndown chart plots the AI token budget a Scrum team has left against the days of the Sprint. It shows whether agent spend is on track, ahead of plan, or stalled, so the Developers can inspect it at the Daily Scrum and adapt their plan.
How is a token burndown chart different from a Sprint burndown chart?
A Sprint burndown tracks the work remaining in the Sprint Backlog. A token burndown tracks the AI budget remaining. The first tells you how much is left to do; the second tells you how much machine capacity is left to do it with. Neither tells you whether the work is verified, which is why the token burndown should be read next to a verified-work line.
Is a token burndown chart part of Scrum?
No. The Scrum Guide does not require any burndown chart. Burndowns, burn-ups and cumulative flow diagrams are complementary practices teams may use to forecast progress. They support empiricism but never replace it.
Who owns the token burndown chart?
The Developers, because the chart is a view of their Sprint Backlog and their plan. The Product Owner uses it to understand cost-versus-value trade-offs, and the Scrum Master coaches the team so the chart stays a transparency tool rather than a cost-control stick.
Should a token burndown measure tokens or money?
Use money (or a normalised cost unit) when the team uses more than one model, because input, output, cached and reasoning tokens are priced differently across models. Raw tokens are fine for a team on a single model with a flat price.
What should a team do when the token budget runs out mid-Sprint?
Stop and inspect before topping it up. Find where the tokens went, check whether the Sprint Goal is still achievable, and involve the Product Owner if scope or budget needs renegotiating. Any top-up should be visible on the chart as a step up, never silent.
