Estimating in AI Tokens

A token is the unit large language models read and write text in — very roughly, three-quarters of a word. Every prompt, every file an agent reads, every revision it generates consumes tokens. When you estimate a task in tokens, you are answering a familiar question in a new currency: "how much work is this?" — where work now means the volume of AI back-and-forth needed to get to a merged change. Like story points, a token estimate is deliberately approximate. Nobody can predict an exact token count for a feature any more than they can predict exact hours. The value is in the relative sizing: a one-line config tweak is a few thousand tokens; a cross-cutting refactor is millions.

Token estimation has one property story points famously lack: tokens add up. Story points are intentionally non-linear — a 13 is not "five more than an 8" of anything, which is why summing them across a sprint is statistically dubious. Tokens are a real, countable quantity, so a sprint total of "3.2 million tokens" is a meaningful number. There's a practical payoff, too: tokens convert to money. At a blended rate of dollars per million tokens, a sprint backlog turns into an approximate compute cost. An estimate can then answer "what will this sprint cost to build?" — not in salaried hours, but in the actual spend of running the agents that do the work.

A token deck works like any other planning-poker scale, just with token-sized buckets that climb exponentially so the team estimates by order of magnitude rather than false precision: 1K · 5K · 25K · 100K · 500K · 2M Each step is roughly five times the last — the same exponential spacing that makes the Fibonacci scale work, so the cognitive habit carries straight over. A "?" card still means "I don't have enough information to estimate," and instead of the traditional coffee cup for a break, a token deck uses an oil drum — the robot's equivalent of needing a top-up.

The optional piece is a single rate: dollars per one million tokens. Set it to whatever reflects your own blended cost across the models you run, and each agreed estimate picks up an approximate dollar figure beside it. A story sized at 500K tokens at a $15/1M rate shows as roughly $7.50. Across a backlog, those add into a running total — "this sprint is about 3.2M tokens, roughly $48 in compute, with two stories still unestimated." It is an order-of-magnitude sanity check, not an invoice: real token use depends on the model, the split between input and output, retries, and how much context each task drags in. Treat the number as a directional signal, exactly as you would a story-point total.

Token estimation is not a replacement for story points everywhere. It earns its keep when AI agents are genuinely doing a large share of the implementation, when your team wants visibility into compute spend, or simply when a planning session needs a bit of fun. For teams where humans still write most of the code, classic story points remain the better model of effort. Really, estimating in tokens is an experiment in what "effort" means when a model, not a person, does the work. You don't have to believe it replaces points to get something from it: once a sprint's work shows up as a dollar figure, it's easier to ask what's actually worth building.

Token cost correlates only loosely with how hard a task feels to a human. The things that move it are mostly about context and iteration: • How much code the agent must read before it can act. A change touching one well-isolated module is cheap; one that requires understanding six interlocking services is not. • How many attempts it takes. Work with a fast, reliable test suite converges quickly. Work verified by a slow manual check burns tokens on every round trip. • How much output it produces. Generating a large migration or a broad refactor costs in proportion to the diff. • Whether the codebase is legible. Clear naming, types, and tests cut consumption substantially, because the agent spends less effort inferring intent. • How well specified the task was. Ambiguity gets paid for in retries. The practical consequence is that a task can be conceptually trivial and expensive, or conceptually gnarly and cheap. A one-line fix in an unfamiliar 200-file service may cost more than a well-scoped feature in a module the agent has already seen. This is precisely why token estimates and point estimates can diverge, and why some teams find it worth tracking both.

Token estimation needs anchors for the same reason story points do, and they are easier to build because the feedback is measurable — most tools will tell you what a session actually consumed. Start by recording the real usage for a handful of finished tasks across the range: a small bug fix, a routine feature, and something that required substantial exploration. Those become the reference points for the 5K, 25K, and 100K cards. After two or three sprints of comparing estimates against actuals, the deck calibrates surprisingly fast — considerably faster than story points, because the ground truth is a number rather than a judgement. Expect the anchors to move as your tooling changes. Better context management, a tighter test loop, or a model that needs fewer attempts will all shift consumption downward without the work getting any simpler.

The two units answer different questions and neither subsumes the other. Story points answer "how much of the team's capacity does this consume?" Tokens answer "what will it cost to run?" A task can be low on one axis and high on the other, and the interesting cases are the ones where they disagree. A story that is cheap in tokens but expensive in points usually means the difficulty is human: a decision to be made, a design to be agreed, a stakeholder to be convinced. Automation will not help. A story that is expensive in tokens but cheap in points often means mechanical bulk — a wide but shallow refactor — and is a good candidate for delegating to an agent and reviewing the result. Teams that track both tend to use points for sprint capacity, as before, and tokens as a budget line that makes the cost of AI-assisted work visible before it is incurred rather than at the end of the month.

Token sizing is a young practice and it is worth being candid about where it is weak. Estimates are noisier than story points at the individual task level, because a single unexpected retry loop can double consumption. The numbers only aggregate meaningfully across a sprint. Pricing also moves — a deck calibrated against one model's rates can be wrong by a large factor after a provider changes pricing or the team switches models, so treat the cost column as indicative rather than a budget commitment. It is also a poor fit for work that is mostly human. Design, discovery, stakeholder alignment, and incident response consume almost no tokens and a great deal of capacity. A team that sized everything in tokens would systematically under-weight exactly the work that most needs planning attention.