What this calculator is for
Once a Scrum Team pays for AI agents, someone in Sprint Planning will ask whether the team can afford an item. Most teams answer by checking one number, the token budget. That misses the constraint that usually bites first: the time people have to verify what the agents produce.
This calculator checks three capacities together. The human capacity is the Developers' focus hours. The token capacity is the AI budget after a reserve. The review capacity is the hours that people able to judge agent output can spend doing it. The Sprint can only hold what the tightest of the three allows.
It doesn't reorder anything. Ordering the Product Backlog is the Product Owner's accountability, and how much to take on is the Developers' forecast. The tool walks your items in the order you give it and shows where each capacity runs out, so that conversation starts with numbers instead of guesses.
How the calculator works
Each item gets a size with one click. The size sets three values: the hours a person needs to build or brief the work, the hours someone needs to review the agent's output, and the tokens the agent is likely to use. These are the starter values:
| Size | Build hours | Review hours | Tokens (M) | Typically |
|---|---|---|---|---|
| S | 1 | 1 | 0.3 | A small fix or change |
| M | 2 | 2 | 0.7 | A typical feature |
| L | 3 | 4 | 1.6 | A larger feature, a migration or a refactor |
| XL | 4 | 6 | 3.2 | Usually worth splitting |
| Person | 16 | 0 | 0 | Human work, no agent |
The token values match the starter bands in the User Story Token Estimator. They are illustrative, so change them under Advanced once you know what your own items use. Items sent from the estimator keep its token figure for each story, which is already adjusted for how vague the story is.
Usable token budget = Budget × (1 − reserve %)
Item token cost = Tokens for its size × (1 + rework allowance %)
Item human load = Build hours + Review hours
Fits when, after adding the item, human load ≤ focus hours, review hours ≤ review capacity, and token cost ≤ usable budget
Flagged when one item's token cost is above the flag % of the usable budget, or when an agent item has no review time
Items are checked one at a time in Product Backlog order. If an item doesn't fit, it is marked with the capacity it breaks, and the calculator keeps going. Later items that still fit are marked "Fits if earlier item is set aside", because skipping an item is a Product Owner and Developer decision, not something a calculator should make.
Worked example
The example loaded above is a team with 120 focus hours, 12 review hours, and a budget of 10 million tokens with a 15% reserve (8.5 usable) and a 20% rework allowance.
| # | Item | Size | Result |
|---|---|---|---|
| 1 | Checkout address validation | L | Fits |
| 2 | Order history export | XL | Fits, flagged for refinement |
| 3 | Payment retry banner | Person | Fits |
| 4 | Admin audit log API | M | Fits |
| 5 | Pricing module unit tests | M | Over review capacity |
| 6 | Cart accessibility fixes | Person | Fits if item 5 is set aside |
| 7 | Search filter by brand | L | Over review capacity and token budget |
| 8 | Invoice PDF redesign | Person | Fits if items 5 and 7 are set aside |
Taking every item would need 9.4 million tokens against 8.5 usable, so the token budget looks like the problem. It isn't the first one. Review capacity runs out at item 5, with 14 review hours needed against 12 available. The people still have spare hours; the people who can verify agent work don't. Tokens only become a limit two items later, at item 7.
The useful options are to grow review capacity (pair a less experienced Developer with a reviewer), refine item 2 so it becomes smaller, or let the Product Owner decide whether items 5 and 7 wait for the next Sprint.
Using the result in Sprint Planning
- Agree the Sprint Goal first. Run the numbers in Topic Two, when the Developers and Product Owner discuss what can be Done.
- Treat a flagged item as a refinement question first. A large token estimate often means vague acceptance criteria, not an expensive feature.
- If tokens are the tightest constraint, look at who does the work before the budget. Moving an item to Person is often cheaper than topping up.
- If review is the tightest, don't add more agent work. Generated work that nobody verifies becomes verification debt.
- Carry the agreed budget and reserve into a token burndown chart so the team can inspect spend during the Sprint.
Frequently asked questions
What does the Sprint Token Budget Calculator check?
It checks three capacities together: the Developers' focus hours, the AI token budget, and the hours people can spend reviewing agent output. It walks the candidate Product Backlog items in order and shows which capacity runs out first.
What do the sizes mean?
Each size stands for typical build hours, review hours and tokens for one item. S, M, L and XL are agent work; Person is human work that uses no agent tokens. The starter values are illustrative, and you can change them under Advanced or edit a single item.
Does the calculator reorder the Product Backlog by token cost?
No. Ordering the Product Backlog is the Product Owner's accountability, so the calculator keeps your order. It only shows where each capacity runs out, and flags items whose token estimate is unusually high so the team can discuss them.
Why is review capacity separate from human capacity?
Review time comes out of the same people's hours, but not everyone can verify every kind of agent output. Review capacity is the share of focus hours held by people who can judge that work, and it is often the first constraint a team hits.
What unit should I use for the token budget?
Use millions of tokens if the team works with one model at a flat price. If the team uses several models, use money or credits, because input, output, cached and reasoning tokens are priced differently.
Is my data stored anywhere?
No. All calculations run in your browser and nothing is sent to a server. Only your Advanced settings are remembered on your device.