An AI generated estimate can look reassuringly precise.
Give the tool a story description, ask for a number, and it will often provide one with a convincing explanation. But a well written explanation does not mean the tool understands the team’s codebase, testing constraints, or unresolved questions.
The estimate may look finished before the understanding is there.
Atlassian describes story points as relative estimates that consider effort, complexity, and risk rather than specific hours or days. Their meaning comes from a team’s comparisons and collective experience, not from a universal calculation.
That distinction matters even more when AI enters the conversation.
Use AI to reveal what is missing
A useful starting prompt is not, “How many points is this?” It is, “What would the team need to understand before estimating this responsibly?”
An approved assistant could identify ambiguous acceptance criteria, missing failure scenarios, unclear integration boundaries, or assumptions about test data. It could also help locate relevant completed stories within information the team is authorized to use.
Those comparisons need context. A story with similar wording may have involved a different architecture, a different team, or a dependency that no longer exists. Similar text does not establish similar effort.
The team should choose its own reference stories and explain what makes them useful. AI can organize that discussion without deciding its outcome.
AI assisted coding may reduce the time spent producing an implementation, but the story still includes review, security checks, integration, testing, and the team’s Definition of Done. Do not automatically halve an estimate because a tool generated the code quickly. Revisit the comparison only when the team has evidence about the complete work, including correction and rework.
Do not let the first number anchor the room
If an assistant announces an estimate before people think independently, the conversation may become an argument about its suggestion rather than an exploration of the work.
One practical approach is to ask team members for their initial views first. Then use AI generated questions to investigate the differences. Someone may be thinking about the interface while someone else is accounting for migration, rollback, and testing.
In Scrum, the Developers who will do the work are responsible for sizing. The Scrum Guide does not require story points or prescribe an estimation formula. AI assistance should not move that responsibility to a tool or a manager.
A hypothetical estimation example
Consider a hypothetical team estimating a story to change a player’s display name. The interface change appears familiar, and an assistant finds an older profile editing story as a possible reference.
Instead of adopting that earlier estimate, the team asks what is different. A developer identifies name uniqueness rules. A tester raises moderation and localization cases. Another team owns a downstream cache that may delay the visible update.
The assistant helps turn those concerns into clarification questions. The team discovers that the cache behavior is not understood well enough to estimate confidently, so it agrees to investigate before sizing the full story.
That is not a failure to estimate. It is a useful decision about uncertainty.
Keep points out of the performance conversation
There is no universal conversion from points to hours, and estimates should not become individual productivity scores. Comparing teams by their point totals ignores that each team may use different references and practices.
If leaders need a delivery forecast, discuss historical delivery patterns, current capacity, dependencies, and uncertainty separately. Do not make a point value promise a specific completion date.
As the team learns, review why its expectations differed from reality. Perhaps the acceptance criteria changed. Perhaps an integration was less predictable than expected. Use that learning to improve the next conversation, not to punish the previous estimate.
Start with one refinement session. Let AI prepare questions and candidate comparisons, keep the initial assessment with the people doing the work, and record unresolved assumptions. The goal is not to make estimation look more scientific. It is to make planning more honest.