Sprint estimation with Cursor and other AI coding tools

13 October 2026 · 13 min read

Somewhere in the last year your team's estimates got strange. One developer votes a 2 on a story because "Cursor will knock that out in an afternoon", another votes an 8 because they've spent a week untangling what an agent wrote last time, and the story takes something nobody voted for. The cards haven't changed, but the way the work gets done has, and the team hasn't agreed what that means for a number. This guide is about getting that agreement: what AI coding tools really change in a sprint, what they don't, and how to run estimation so the numbers mean something again.

What actually changed

AI coding tools, whether it's Cursor, Claude Code, GitHub Copilot or whatever your team settles on next quarter, are very good at one part of the job: turning a clear intention into working code. Boilerplate, wiring, tests for code that already exists, the third form that looks like the first two. That part used to take a real share of a sprint, and now it takes much less.

Everything around it costs about what it did before:

• working out what the story should actually do, including the cases nobody wrote down;
• gathering the context the tool needs: which files, which conventions, which history;
• reviewing what comes back, and catching what's plausible but wrong;
• integrating it: migrations, feature flags, deploys, the other team's API;
• testing the parts that can't be tested by the code that was just generated.

So the work didn't shrink evenly. Some stories collapsed to a fraction of their old size and some barely moved. And a few got bigger, because a tool produced a large, confident change in an area where a small, careful one was needed.

Why your estimates got noisy

The biggest source of noise usually isn't the tool. It's that people are voting on different workflows without saying so. On a team of five you can easily have:

• someone who uses autocomplete and writes the rest by hand;
• someone who chats with the tool file by file;
• someone who hands whole stories to an agent and reviews the result;
• someone who doesn't trust any of it for this part of the codebase, with good reason.

Each of them votes honestly for the way they would do the story. Their numbers differ by a factor of four and they're all right, about four different stories. Planning poker was designed to expose exactly this kind of hidden assumption; it only works if the discussion after the reveal asks the right question. The first one to add is: "How were you picturing building this?"

The fix isn't to force everyone onto one workflow. It's to estimate the work, not the tool: the decisions, the unknowns, the review and the risk, which are the same whoever or whatever types the code. Story points were always meant to measure that, as we explain in story points: complexity and capacity. AI tools make the difference between "effort" and "typing" impossible to ignore.

The stories AI changes most, and least

It helps to sort stories by how much context they need, because that predicts better than anything else how much an AI tool will help. Here's a rough map we've found useful:

Naming the kind out loud during estimation settles a lot of arguments. "It's a local change" and "it touches the permission model" are two different stories, even if the ticket title is the same.

Call out the context-heavy tickets

A human developer builds up context over months and carries it into every story. An AI tool starts every session close to empty and only knows what it's given or can find. So a story's context weight is now a real part of its size. Before the vote, it's worth running down a short list for each story:

1. Files. Which parts of the codebase does it touch, and which should it copy?
2. Conventions. Are there project rules or agent instructions the tool needs, and are they written down anywhere it can read?
3. Logs and data. Does it need production logs, a bug report, a sample file, a database shape? Who can get them, and are they safe to share with a tool?
4. Tests. Is there a test suite that will tell the tool when it's wrong? If not, writing that comes first, and it's part of the estimate.
5. Product context. Designs, edge cases, wording, the decision from last month's meeting that isn't in any ticket.
6. Other people. Does anything need another team, a security review or a sign-off? No tool shortens a queue.

A story where every answer is "it's all in the repo" is a good candidate for heavy AI help. A story with three answers of "ask Marta" is mostly a people problem, and should be estimated like one.

Two numbers per story: points and a token band

Story points still carry the most important information: how complex, uncertain and risky the work is, and how much careful human attention it will take. Keep them. But if your team runs a lot of work through agents, a second, rougher number earns its place next to them: how much model usage the story is likely to need, retries included.

That second number is a planning signal, not a price, and it should stay coarse: a band, like "around 250k tokens", not a figure like 213,400. The two numbers often disagree, and the disagreement is the interesting part:

• Low points, low tokens. A well-understood local change. Let the tool do it, review it quickly, move on.
• Low points, high tokens. Simple but big: a rename across hundreds of files, a migration of every form to a new component. Mechanical, but expensive in context. Consider splitting it so each piece fits in one session.
• High points, low tokens. Small change, hard decision. A two-line fix to the pricing rules. The tool will type it in seconds; the review and the conversation are the work.
• High points, high tokens. Big and hard. This is where AI-assisted stories go wrong most expensively. Split it, spike it, or estimate it again once the unknowns are known.

Storyvote has an AI tokens deck for the second number, with cards from 10k to 10M+. The simple way to use both is one room: pick your points deck, and turn on the AI tokens extra question in Settings, so every vote asks for a points card and a token band at once, and both are saved on the story. We go deeper into how to choose a token card, and why retries make stories more expensive than they look, in budget for the retry.

Facilitating the round

Most of the value is in the conversation after the cards turn over, and AI tools add a few new ways for that conversation to go sideways. Some habits that keep it useful:

• Vote before anyone asks the tool. It's tempting to paste the ticket into Cursor in the middle of the meeting and see what happens. Don't, at least not before the vote. A demo anchors everyone: you lose the independent estimates, and the disagreement that would have shown you where the ticket is thin. If the team wants a quick experiment, make it a separate step after the first vote.
• Ask the outliers which workflow they pictured. The low voter is often imagining an agent doing it end to end; the high voter is often imagining the review. Both are part of the story.
• Treat "it's one prompt" as a claim, not an estimate. Ask what the prompt would say. If nobody can write it in two sentences, the story isn't ready, and that's what the vote has just told you.
• Watch for tool optimism and tool pessimism. Optimists price stories at the speed of a good demo. Pessimists price them at the cost of the last bad experience. Both are evidence; neither is the estimate. The middle of the reveal usually is.
• Keep the clock. AI discussions are fascinating and endless. Give each story a timebox and park the general debate about tools for the retro.

Review is the new bottleneck

When building gets faster, the queue moves to review. A team that used to finish ten stories a sprint might now produce twenty pull requests, and the same three senior people have to read all of them carefully. If you plan the sprint around how much can be built, you'll end it with a pile of open pull requests and a tired team.

A few ways to plan for it:

• Estimate the review too. In Storyvote you can do this with disciplines: set up the room with Build and Review, pick both when you add a story, and each part gets its own vote and its own row. A story that's a 1 to build and a 5 to review is telling you where the sprint's time will really go.
• Plan review capacity like any other capacity. Count the hours your reviewers actually have, the same way you'd plan the team's capacity, and stop pulling stories in when that runs out, not when the builders do.
• Limit open AI pull requests. A work-in-progress limit (say, two per reviewer) keeps changes small enough to read properly.
• Prefer small changes. A tool can write a 2,000-line pull request as easily as a 200-line one. A person can't review them equally well. Split stories so each change can be read in one sitting.

Velocity while the team adopts AI tools

Expect a messy few sprints. Teams adopting AI tools often see velocity dip first (learning, setting up instructions, cleaning up early mistakes), then jump, then settle somewhere new. None of those numbers is the "real" one while it's moving. Some advice for that period:

• Re-pick your reference stories. If your old "3" was mostly boilerplate, it's not a 3 anymore. Choose a new reference story together, from recent work, and size against that.
• Don't deflate points to match the tool. Voting everything lower because "we have AI now" just breaks the scale. If the work genuinely got smaller, velocity will rise on its own.
• Plan on a short average. Use the last three sprints, not the last ten, until the numbers settle.
• Don't compare with last year. Points are only comparable within one team at one time. A jump in velocity after adopting a tool is a change of scale, not a performance review.
• Look at cycle time too. How long a story takes from "in progress" to "done" shows where work waits. If it's mostly waiting for review, that's where to invest.

A sprint planning agenda for AI-assisted teams

A 90-minute planning meeting, adjusted for teams that build with AI tools:

1. Goal (10 min). The sprint goal, and the capacity of builders and reviewers.
2. Context check (10 min). Run down the top stories: what kind is each (local, module, cross-cutting, archaeology, discovery), and is the context for it written down?
3. Estimate (45 min). Planning poker on points (and, if you use it, a token band), with a timebox per story and "how were you picturing building this?" after every wide reveal.
4. Write it down (15 min). Turn each discussion into the ticket the tool will read: the goal, the files to start from, what's out of scope, how to tell it works. Our guide to planning poker when AI agents write the code has a template.
5. Commit (10 min). Pull in stories until either building or review capacity runs out, whichever comes first.

Assumptions and limits

A few honest caveats about everything above:

• Tools change faster than processes. What a tool can do this quarter isn't what it could do last quarter. Re-check your reference stories every few months.
• Token numbers are rough. Usage depends on the tool, the model, how it manages context and what's cached. Use bands, compare within your own team, and don't treat them as a bill.
• Not everything should go through a tool. Code under strict compliance rules, sensitive customer data or secrets may not belong in any third-party tool, whatever the estimate says. Settle that as a team policy, not story by story.
• None of this replaces judgment. An estimate is a shared guess, made better by people disagreeing out loud. That part hasn't changed.

Questions teams ask

Should we estimate lower now that we use AI tools?

No. Estimate the work honestly against a reference story, and let velocity show the change. If you shrink the numbers by hand, you count the speed-up twice: once in the smaller points and again in the higher velocity.

Can the AI estimate the stories for us?

It can suggest a size, and that can be an interesting input after the team has voted. Before the vote it anchors everyone, and the gaps that the spread of votes would have shown stay hidden. The team still has to own the number, because the team does the review.

Do we need a separate velocity for AI-assisted work?

Usually not. A separate velocity invites arguments about which bucket a story belongs in. One velocity, with reference stories chosen from recent work, works better. If you want to see the effect of the tools, look at cycle time and review time instead.

What about junior developers?

AI tools can make a junior developer fast at writing code before they're fast at judging it. That raises the review cost of their stories for a while, which is fine, and worth planning for: pair them with a reviewer on cross-cutting work, and let estimates reflect the review.

Does Storyvote connect to Cursor or other AI tools?

No, and it doesn't need to. Storyvote is where the team agrees what a story is and how big it is; the tools are where it gets built. You can import your stories from a CSV and download the estimates as one afterwards, which is enough to move work between the two.

Try it with your team

Create a Storyvote room, add your next sprint's stories, and ask the new question after every reveal. Use Fibonacci for points and the AI tokens extra question for the usage band, both in the same round. It's free, nobody needs an account, and the whole team joins from one link.

← All articles