Agile Estimation in the Age of AI: Keep the Team Conversation

Someone on your team shipped a working feature in an afternoon with an AI assistant. Now they're asking why you still spend an hour in refinement debating whether a story is a 5 or an 8. It's a fair question for agile estimation in the age of AI. You've probably heard the louder version too: agile is outdated, and estimation is a leftover from slower times.

You don't have to win that argument to get something useful out of it. AI changes how fast code gets written. Your team still has to agree on what a story involves, and that agreement comes from talking. A short estimation round is one of the cheapest ways to start that talk, as long as you use it to surface assumptions.

The claim: AI makes agile and estimation obsolete

The argument starts with speed. In a post from 13 October 2026, engineering manager mtx2s describes the mood they've been seeing: "The sentiment is that 1-2 week sprints are too long, or that more time is spent on meetings and ticket management than on writing code." When an assistant drafts a feature in hours, a two-hour planning event can feel slow.

mtx2s doesn't accept the conclusion, though. They write, "However, viewing Agile as outdated for these reasons seems to miss the essence of Agile." Their diagnosis is narrower: "If you feel that Scrum events are overhead, it may be that the development methodology you are practicing using Scrum is no longer suited to the changes following the introduction of AI." In other words, the way you run the events may be the problem. And agile has always asked teams to adapt how they work, so changing an event's format is part of the idea.

Others see a wider rethink. Naveen Kumar Singh, an agile coach writing for Agilemania in March 2026, says software development methods are being re-examined as "the Agile Manifesto marks its twenty-fifth anniversary and agentic artificial intelligence becomes industrialized." He also writes that "the debate over updating agile frameworks to fit an AI-driven landscape is now urgent for tech leaders and managers."

The Hups blog goes further. Its author says agile practices rest on assumptions about people: "Most Agile practices and principles are based on assumptions about human behavior and team productivity. Some of these assumptions still hold true, but some need to be challenged and reevaluated, and this will impact the practices."

Be honest about what kind of evidence this is. You've got a practitioner's blog, a commentary piece and a training provider's article. It's all opinion and prediction, and none of it measures what happens to estimates. The Hups author admits as much: "To be clear: I don't know where we will land. But I'm pretty sure that things will change, as the underlying assumptions behind many of the agile practices are overturned by the advent of Generative AI."

That uncertainty is useful, because it gives you a reason to look hard at your own events. When someone calls refinement overhead, ask which conversation it was meant to protect, and whether that conversation now happens anywhere else.

What agile estimation in the age of AI was always for

Estimation earns its time through the discussion it starts. The number is a side effect. A story point is a rough size, and any forecast you build on it will be off in ways you can't see yet. A good round gives you something sooner: five people who read the same story five different ways find that out before anyone starts building.

If your team's stated reason for estimating is "so we can predict the sprint," try another one: "so we all understand the story before we start it." With the first, a wrong number feels like failure. With the second, a split vote feels like progress, because it shows you where the understanding breaks.

There's some survey data behind this, with caveats. A ThinkCloudly post relaying Easy Agile research says "Only 31% of teams use collaborative estimation techniques, meaning most miss the hidden complexity surfaced by group discussion". It also reports that "55% of teams estimate in time rather than story complexity, which papers over uncertainty". Handle both figures with care. They reach you second-hand, and the post itself promotes AI sprint planning.

Time estimates get even shakier when AI changes how long the typing takes. Ask "how long will this take?" and everyone answers from their own tools and habits. Ask "how big and uncertain is this?" and the conversation moves to the work itself.

As mtx2s writes, "Humans are not good at hitting the right answer through desk analysis alone." That fits estimation well. One person reading a ticket alone misses what a tester, or the engineer who knows the old module, would spot quickly. Sizing together gets more of those views into the room early.

If planning poker is new to anyone on your team, the basics of a first session are worth a read before you change anything.

Where AI-assisted work changes the conversation

AI help adds assumptions to every story, and your team needs to say them out loud. Two people can read the same ticket and picture different work, depending on how they expect the code to get written.

Faster code doesn't settle the question. ThinkCloudly cites a report saying that "while AI tools now write 41% of all code, delivery stability has actually decreased by 7.2% at many organizations". Same caveat as before. It's a secondary figure, so read it as a signal. Still, it's a fair reminder that code arriving quickly and software running reliably are two separate outcomes.

Singh writes that "rapid AI development makes rigorous documentation and thoughtful architecture even more critical to prevent hidden flaws." Bring that into sizing. A story that looks small because an assistant can draft it may still need someone to write down the constraints and check the design.

Then there's oversight. The Hups author says "The AI models are not perfect yet, they do need human oversight". Oversight is work: someone has to review the generated code and test it properly. If your estimate only counts the drafting, that work goes missing.

Expect the answers to differ. Someone who uses an assistant all day and someone who rarely does will size the same story differently, and both can be reasonable. Before you vote on an AI-assisted story, these questions bring the hidden work into the room:

• How much of the code do we expect an assistant to draft?
• Who reviews it, and how closely?
• Which tests do we need to write or check ourselves?
• Does it touch an area where a quiet mistake would be expensive?

A refinement routine that keeps the human conversation

You don't need a new event for this. A short routine inside your existing refinement keeps the conversation and caps the time, and it works with any planning poker setup, physical cards included.

1. State the AI assumption. Read the story, then state the AI assumption. The product owner reads the story aloud. Before anyone picks a card, each person says in one line how much AI help they're assuming: "assistant drafts most of it," "I'd write this by hand," or "drafted, but the tests are on us."
2. Reveal together. Vote in secret, then reveal together. Secret votes stop people drifting toward the first number they hear or the most senior voice in the room.
3. Hear the outliers. Hear the outliers first. Ask the highest and lowest voters to explain before anyone else speaks. Their reasons usually contain the assumption nobody else said out loud. If your splits tend to sprawl, there's more on hearing outliers without derailing refinement.
4. Re-vote once. After the outliers speak, vote again. One re-vote usually shows whether the team has converged, so I'd stop there.
5. Accept, split or park. Accept, split or park, and cap the time. If the votes are close, accept and move on. If they still diverge, the story probably holds more than one piece of work, so split it, or park it until someone finds the missing fact. The post on when to re-vote, split or park a story goes through those calls. Agree on a time limit per story before you start, and stick to it.

If you run this online, TinyTroop is free online planning poker that keeps votes secret until the reveal and names the outlier votes, so your team knows whom to hear first.

Say one story gets a 3 and a 13. The 3 assumes an assistant drafts the code and the job's mostly done. The 13 assumes someone has to review that code and write tests around it. Both voters are right about the part they're picturing.

Name the gap out loud, then fix the story. You can add the review and test work to the acceptance criteria so everyone can see it, or split the story by behavior so each piece is small enough to check properly. When you vote again, everyone's sizing the same work.

Keep what helps, drop what doesn't

Judge every event by the conversation it protects. Refinement protects the moment your team finds out it disagrees about a story. Sprint planning protects the moment you agree on what you'll try to finish. If an event still protects its conversation, keep it, even if it feels slow next to AI-assisted coding.

Change the format before you drop the conversation. A long refinement can usually get shorter with a tighter agenda, and running a refinement that ends on time shows one way to get there. That's mtx2s's point too: when events feel like overhead, the way you run them may be what no longer fits.

At your next refinement, try the routine on a handful of stories. At the end, ask the team one question: what did you learn from the disagreements? The answers will tell you more about whether estimation still earns its place than any opinion piece, this one included.

AI can draft the code. But your team still has to agree on what the story means, and a quick secret vote is one of the fastest ways to find where you don't.

If you'd like that vote to come with card flips and a shower of confetti when everyone lands on the same card, Start a free room and try the routine on your next story.