Your sprint planning is missing a column

In 2022, story points made sense as the single unit of estimation. A feature cost roughly N engineer-weeks. Infrastructure was a background cost that Finance worried about and you didn't. AI tools in the engineering workflow were optional, and when they existed they were cheap enough to be invisible.

Three years later, a large fraction of engineering work in serious teams is being done by models running quietly in the background. Drafting initial implementations. Generating the first pass of tests. Refactoring. Writing migration docs. Reviewing pull requests. Running evals in CI. None of that compute is free, and in the teams I've looked at carefully, the model-compute spend for marginal feature delivery now rivals the marginal engineering salary cost. Sometimes it's higher.

What a token-budget column actually means

Concretely, you do the thing your finance team has been doing for twenty years and your engineering team has somehow avoided. Per-story, you forecast the expected token spend: for prototyping, for iteration, for the agent runs that ship with the CI pipeline, for the deployment validation. You sum it at sprint level. You track forecast against actual at the retrospective. That's it.

The first version can be primitive. Categories: S, M, L, XL. S is a few cents of compute, XL is a feature whose agent-driven development burns through a couple of hundred dollars of tokens before it merges. You don't need a precise number. You need a number that is anchored to reality and improves with each sprint.

The advanced version separates the pools. Prototyping tokens are cheap and you should burn them freely. Production inference is expensive and you should treat it as scarce. Agent-driven operations (the CI agent fixing a flaky test, the on-call copilot drafting a post-incident note) are a third class with their own burn rate. Having three rough budgets beats having none and discovering the invoice at month-end.

The objections

The first objection is always "isn't this just cloud cost?" It isn't. Cloud cost is a fixed-ish overhead that scales slowly with your team. Model compute scales with how you build features and which models you choose, often by an order of magnitude between one implementation path and another. It is a variable cost that moves with engineering decisions, which makes it an engineering problem, not a finance one.

The second objection is that token costs will come down and this will all stop mattering. Maybe. We said the same about cloud compute in 2010, and cloud compute did come down, and total cloud spend still went up every year since because we found new things to put in it. The price floor dropping does not mean the budget column stops existing.

You can't manage what you don't forecast.

The interesting part

None of this is hard. A token-budget column in your planning tool is a spreadsheet change. What's interesting is that almost no planning tool ships this out of the box, and almost no engineering organisation has thought carefully about adding it. The ritual of sprint planning evolved for a particular economic model that quietly stopped being true around 2024, and we're still performing the old ceremony.

The teams that add the column in 2026 will have a much easier time explaining themselves to finance in 2027. And the teams that don't will spend the same year being asked why their AI spend climbed without a coherent answer.