Planning poker when AI agents write the code

12 October 2026 · Updated 13 October 2026 · 9 min read

A ticket goes in, a pull request comes out twenty minutes later. With an AI coding agent on the team, it's tempting to think estimation is a ritual from the slow old days: why spend half an hour sizing work that a machine will finish before lunch? We think the opposite is true. The faster the implementation gets, the more of the work moves to the part planning poker was always good at: working out, together, what the story actually is.

The bottleneck moved

For most of software's history the expensive part was writing the code. Planning existed to make sure that expensive time went to the right things. Agents change the price list. Typing out an endpoint, a form or a migration is now cheap. What stays expensive is everything around it:

• Deciding what should be built, and what shouldn't.
• Describing it well enough that someone else can build it.
• Reviewing what came back and catching what's wrong with it.
• Integrating it with the rest of the system without breaking things.

The first two happen before the work starts, which is exactly where planning poker sits.

An agent never raises its hand

Give a vague ticket to a developer and they come back with questions: does "export" mean CSV or PDF? Should this use the existing date picker? What happens when the list is empty? Each question is a small cost, but each one also fixes a gap in the spec before it becomes code.

An agent mostly doesn't ask. It fills every gap with a reasonable guess and keeps going, and the result looks finished. It compiles, it has tests, it reads well. The guesses only surface in review, when someone notices a new library where an existing helper would do, a component that duplicates one three folders away, or an error state nobody designed. Now the reviewer has to find every assumption, explain the right answer and wait for another pass. The twenty-minute pull request has turned into two days of back-and-forth.

A thin ticket was always a problem. With an agent it's a problem you discover later, when it's more expensive to fix.

The conversation was always the point

The number at the end of a planning poker round was never the most valuable thing it produced. The valuable part is the minute before it: everyone sizing the story privately, then seeing that one person voted 2 and another voted 13. That gap means two people are picturing different work, and the round forces them to say why.

Read that way, a spread of votes is a spec-gap detector. Whatever made your teammates disagree is exactly what an agent would have to guess. If the backend developer voted high because "we'd need to paginate this", that sentence belongs in the ticket. If someone threw the ? card, there's a question nobody can answer yet, and an agent certainly can't. Our guide to reading a reveal covers the shapes a vote can take; every one of them tells you something about the spec as well as the size.

Do story points still mean anything?

Yes, as long as they meant the right thing before. Story points were never hours of typing. They measure complexity, uncertainty and risk relative to a story the team knows. An agent shrinks the typing, but it doesn't shrink:

• the number of decisions the story needs;
• how many parts of the system it touches;
• how hard it is to test, and how bad it is if it's wrong;
• how long a careful human review takes.

What does change is the calibration. If your reference "3" was mostly boilerplate, it may now be a 1, and your velocity will jump for a few sprints before it settles. That's fine. Re-pick a reference story with the team, and don't compare this quarter's velocity with last year's. Points were only ever comparable within one team at one time.

Estimate differently, not more

You don't need longer planning meetings. You need a few extra questions in the discussion after each reveal, the ones a developer would have asked mid-sprint and an agent won't:

• One pass or several? Can this be built and reviewed as a single change, or should it be split into stories an agent can finish, and a human can review, one at a time? Two tiny stories that always ship together may be better merged.
• What to reuse. Which existing modules, components or patterns should it build on? Naming them is the cheapest way to stop a parallel implementation.
• New dependencies. Is a new library allowed, or should it work with what's already there?
• What "done" looks like. Acceptance criteria and the tests that prove them, written so they can be checked, not interpreted.
• The states nobody draws. Empty, loading, error, very long text, no permission. Agents happily invent these, and their inventions rarely match the design.
• Where to look hard in review. Auth, money, data migrations and anything that deletes. Flag them so the reviewer knows where the risk is.
• Which agent instructions apply. If your team keeps project rules or prompt files for agents, does this story need one that isn't loaded by default?

None of these take long. If a story needs ten minutes of them, that's not a failure of the meeting: it's a story that wasn't ready, and you just found out cheaply. Keep the rest of the session moving with a timebox per story.

The ticket is the prompt

The last step is the one teams skip: write the outcome down. Whatever the team agreed out loud goes into the ticket before the next story, in a shape an agent can use:

1. Goal: one sentence on what the user can do afterwards.
2. Context: where it lives and what it builds on.
3. Constraints: what to reuse, what not to add.
4. Acceptance criteria: the checks that say it works.
5. Out of scope: what it deliberately doesn't do.
6. Open questions: anything nobody could answer yet, with the name of whoever will.

A good test: could a new teammate start this story from the ticket alone, without asking anyone? If yes, an agent probably can too.

This isn't a second meeting. Every line comes out of a moment in the round you were already running, and one person types while the room talks:

Here's how it went for a team of four estimating "Let workspace admins archive old projects in bulk." The first vote came back 3, 5, 13 and ?. The 3 pictured a checkbox column and a button. The 13 knew that archived projects still send scheduled reports. The ? asked whether archiving can be undone. Ten minutes later, the ticket said:

Goal: An admin can select several projects and archive them in one go.

Context: Projects list. archive() already exists for one project;
BulkActionBar on the members list does multi-select.

Constraints: Reuse BulkActionBar. No changes under reports/.

Acceptance criteria: Only admins see the action. The confirmation
names how many projects it will archive. Unit tests and the e2e
list test are green.

Out of scope: Unarchiving (its own story). Archiving through the API.

Open questions: Do archived projects stop their scheduled reports?
Tom asks product by Wednesday.

Notice what the 13 turned into: not a bigger number, but an open question and a constraint that fences it off. With the reports question written down and out of the way, the team revoted and landed on 5. You don't have to pad an estimate for a risk you've written down, and the agent gets a ticket that says exactly where not to guess.

Size the review, not just the build

When an agent does the building, the human effort on a story is mostly reviewing and testing. Some teams find it useful to size the two separately. In Storyvote you can do that with disciplines: set up the room with, say, Build and Review, pick both when you add a story, and it's estimated as one row per discipline, with the panel showing the total. A story that's a 2 to build and an 8 to review is telling you something important about where the sprint's time will really go.

Three traps to avoid

• Letting the AI estimate for you. An agent can read a ticket and suggest a size, and that can be a useful input. But if its number is on screen before the team votes, it anchors everyone, and you lose the disagreement that finds the gaps. Vote first, compare after.
• "The agent will figure it out." It will figure out something. Skipping refinement because building is cheap just moves the cost into review, where it's paid by your most senior people.
• Measuring the agent in points. Points describe the work, not who or what did it. Using velocity to grade a tool, or a person, breaks it as a planning signal.

Try it in Storyvote

Storyvote is free planning poker for teams like yours: everyone votes privately, the cards flip together, and the spread shows you where the spec is thin before an agent finds out the hard way. Add your stories, split them by discipline if you want, and download the estimates as a CSV at the end. Nobody needs an account, so the whole team can join from one link.

← All articles