AI token estimation: a card-by-card guide for agile teams

Once a team writes code with AI tools, every ticket has a second size: how many tokens the work will burn. Two stories worth 3 points each can differ by a factor of fifty, because one needs a single file of context and the other sends an agent wandering through half the repository. AI token estimation is a rough forecast of that number, made by the team before the work starts. This guide walks through the scale card by card, so your first round has something to aim at.

What you're estimating

A token estimate is the total a story is likely to use from start to finished pull request: everything the model reads (the task, your agent instructions, the files it opens, test output) plus everything it writes (code, explanations, its own reasoning). Input is usually the bigger share, because an agent reads far more than it writes, and it re-reads a lot of it on every pass.

Three things decide most of the number:

  • Context. How much code the work has to see. A change inside one component is cheap to explain; a change that touches the database, the API and three screens is not.
  • Clarity. How much the agent has to guess. A vague ticket turns into exploration, and exploration reads files.
  • Passes. How many attempts it takes until the checks pass. Each retry carries the history of the ones before it, which is why a budget has to plan for the retry, not just the first try.

You're not aiming for precision. A good token estimate puts a story in the right band, so the team can tell a cheap ticket from an expensive one before anyone opens an editor.

The scale, card by card

Storyvote's AI tokens deck runs from 10k to 10M+, roughly doubling or more at each step, plus a ? for "can't say yet". The steps grow fast on purpose: as with story points, the bigger the work, the less precise anyone can be about it. Here's what each part of the scale tends to mean. Your tool, model and codebase will shift the lines, so treat this as a starting point to calibrate, not a rulebook.

CardsTypical workWhat it signals
10k, 25k A copy change, a config flag, a rename in one file, a one-line fix with a clear cause Hand it to the tool and move on
50k, 100kA focused bug fix or a small feature across a few files, with tests to updateThe everyday ticket; one or two passes
250k, 500kA feature that spans several modules, or a fix in code the team knows poorlyWorth a short plan and a list of files to read first
1M, 2.5M A cross-cutting change, a migration, or work where the agent must explore before acting Write the ticket carefully; agree on when to stop and talk
5M, 10M+A repo-wide refactor or a long agent session with many retriesUsually a sign the story should be split
?Nobody can tell what the agent will need to readThe spec has a gap; talk before you estimate

Start from reference tickets

Teams get consistent story points by comparing new work to work they've already done, and token estimates work the same way. Before your first round, pick two or three stories the team recently finished with AI help and look up what they used (your AI tool or provider dashboard shows usage per session or per API key). Put each one on its card:

  • a small one, say a bug fix that came in around 50k;
  • a typical one, a feature that landed near 250k;
  • a heavy one, something that went past 1M.

Write them where everyone can see them during planning. Now the question in the room isn't "how many tokens is this?", which nobody can answer, but "is this more like the bug fix or the feature?", which everyone can.

Running the round

  1. Read the story out loud. The person who wrote it answers questions; nobody names a number yet.
  2. Everyone votes in private. Hidden votes matter even more here than for points: token estimates are new to most teams, and the first number spoken out loud becomes everyone's number.
  3. Reveal together. If the cards sit within a step of each other, take the result and move on.
  4. If they spread, ask the extremes. The person who voted 25k and the one who voted 1M are almost never disagreeing about tokens. One of them knows the change touches the payment module and the other doesn't. That's the conversation worth having.
  5. Revote once, then decide. A second round after the talk usually converges. If it doesn't, take the higher card and note why.

Our guide on reading a reveal covers spreads in more detail; everything there applies to token cards too.

What a split vote is telling you

A wide spread on the token deck nearly always comes from one of four places:

  • Different context. Someone knows the change reaches further than the ticket says. Write the extra areas into the ticket.
  • Different approach. One person pictured a small patch, another a proper rework. Agree on the approach first; then the number follows.
  • Different tooling. One voter assumed the agent works through it alone, another assumed someone pairs with it and steers. Settle who does the work, then estimate that.
  • A gap in the spec. When several people play ?, nobody can describe what done looks like yet. Don't estimate it; refine it.

Using the numbers

A token estimate earns its keep in a few places:

  • Spotting the outliers. A 2-point story with a 2.5M card deserves a second look: either the ticket is unclear, or the work is a poor fit for an agent.
  • Choosing who builds it. Cheap, clear tickets are good candidates to hand to an agent; expensive, foggy ones often go faster with a person in the lead.
  • Forecasting spend. Add up the sprint's cards for a rough ceiling. Convert to money only when you need to, with the day's prices: rates change, differ between models, and cached input costs less.
  • Learning. At the retro, set each story's card next to what it actually used. Patterns tell you more than single misses: if every story in one module runs three times over, that module needs better tests or clearer agent instructions.

One warning: never compare token usage between people or teams. Like points, the numbers only mean something inside one team, about its own work.

Tokens next to story points, not instead of them

Token usage doesn't replace effort. A story can be cheap in tokens and still cost a senior engineer an afternoon of review, and that afternoon is usually the more expensive part. Keep estimating complexity and risk in points, and add tokens as a second number. In Storyvote you can do both in one vote: keep a points deck and turn on AI tokens as an extra question, so each person picks a points card and a token card, and both are revealed together. Our guide to setting up a room for AI teams shows the whole setup.

Try it with your team

Create a room, choose your points deck, and add AI tokens under extra questions. Everyone joins from one link, no accounts, and the estimates download as a CSV for the retro. To turn those estimates into money, read why a million tokens never has one price.

Put a token forecast on every ticket. Start a free room. No sign-up needed.

← All articles

Enjoying Storyvote? A short review helps other teams find it.