Why sizes instead of detailed estimates
Nobody has time to describe every story in detail before the team even knows whether it will go to an agent. Most teams already give stories a rough size in Product Backlog refinement. This tool builds on that habit: you import or paste the backlog, it suggests a size for each story (or uses the size in your file), and the size picks a token range.
The ranges start from illustrative starter values. After a couple of Sprints, add what your finished items actually used, and each size range becomes your team's own. That is when the numbers become genuinely useful, and it takes one line per item.
What the tool does with each story
1. Agent readiness check
A story with no description or no acceptance criteria is marked not ready straight away: an agent given only a title has to guess everything. For the rest, the tool reads the title, description and acceptance criteria and looks for the patterns that make agents retry and rewrite: vague words such as “fast”, “gracefully” or “user-friendly”; criteria with no numbers to test against; no mention of errors or edge cases; no scope boundaries; and stories that ask for several things at once. These add up to an ambiguity score from 0 to 100. Click “Why?” under a story to see what was found.
2. Suggested size
The suggestion comes from the number of acceptance criteria, moved up one size when the story mentions a migration, refactor, integration or legacy system. It is only a starting point, because the text can't show how much of the codebase the work will touch. That is why changing it is one click.
3. Token range
Each size has a likely figure for a clear story. A vague story raises the likely figure (by up to 60% at an ambiguity score of 100) and widens the range. The totals add up the agent stories; stories marked Person count as human work and use no agent tokens.
Starter size bands
These are the likely figures for a clear story with the default setup (coding agent, standard model, medium codebase). They are illustrative, not measurements of any particular tool or model.
| Size | Typically | Likely | Range |
|---|---|---|---|
| S | 0–2 acceptance criteria, a small fix or change | 332k | 232k–531k |
| M | 3–5 criteria, a typical feature | 744k | 521k–1.2M |
| L | 6–8 criteria, or a migration or refactor | 1.6M | 1.1M–2.5M |
| XL | More than 8 criteria; usually worth splitting | 3.2M | 2.3M–5.1M |
A chat assistant uses roughly a third of an agent's turns, a reasoning model writes about three times as much output per turn, and a large codebase means more context to read on every turn. The setup choices adjust the bands for that. Most agent tools resend the working context on every turn, which is why context, not output, is usually the biggest share of the tokens.
Worked example
The example backlog loaded above has five stories. With the default setup and the suggested sizes, the tool gives:
| # | Story | Readiness (ambiguity) | Size | Likely | Range |
|---|---|---|---|---|---|
| 1 | Export order history (vague) | Not ready (77) | M | 1.1M | 521k–2M |
| 2 | Export order history as CSV (refined) | Ready (0) | M | 744k | 521k–1.2M |
| 3 | Migrate customer addresses from the legacy CRM | Ready (0) | L | 1.6M | 1.1M–2.5M |
| 4 | Fix the login button (title only) | Not ready (75) | S | 481k | 232k–880k |
| 5 | Filter search results by brand | Ready (15) | M | 811k | 521k–1.3M |
| Total, five agent stories | 4.7M | 2.9M–7.9M |
Two things stand out. The vague export story is estimated higher than its refined twin, even though they describe the same feature, because unclear criteria make agents retry. And the login fix is only a title, with no description and no acceptance criteria, so it is marked not ready. It needs refinement before anyone, human or agent, picks it up.
Using it in Scrum
- Run the backlog through it during Product Backlog refinement. Fix the stories flagged as not ready before anyone sizes them.
- The Developers who will do the work own the sizing. The suggested size and the range are input to their conversation, never a commitment.
- In Sprint Planning, send the list to the Sprint Token Budget Calculator. Each story arrives with its size and token estimate, and the calculator checks them against review hours and focus hours together.
- After the Sprint, add each agent item's size and actual tokens in the calibration box. Within a few Sprints the ranges reflect your codebase, not anyone's defaults.
Frequently asked questions
How much input does each user story need?
Almost none. Import the whole backlog from a file or paste it at once. The readiness check runs automatically and the tool suggests a size for every story. You only click a different size where the suggestion is wrong.
Can I import a CSV or Excel file?
Yes. Use a .csv or .xlsx file with the columns Title, Description, Acceptance Criteria and Size. Only Title is required, but a story without a description or acceptance criteria is marked not ready. Download the template from the page to start. CSV exports from Jira and Azure DevOps work too.
Can a calculator predict exactly how many tokens a user story will use?
No. Token use depends on the codebase, the agent setup, the model and how clear the story is, and the same task can cost different amounts on different runs. This tool gives a range for each size, and the ranges become your team's own once you add a few actual results.
Why does a vague story get a higher token estimate?
Vague acceptance criteria are one of the biggest drivers of token cost, because an agent with no measurable target tends to retry and rewrite. A higher ambiguity score raises the likely figure and widens the range for that story.
Is my backlog sent anywhere?
No. Everything runs in your browser and nothing is sent to a server or to an AI model. The tool remembers only your team setup and calibration figures on your device, never the stories.