Can AI estimate story points for you? Does it actually work?

Yes, with a specific and fairly narrow meaning of 'works': an AI model reading a ticket's title and description can produce a plausible story-point estimate, and it's genuinely useful as a second opinion — particularly at flagging the ticket that's been sized like a 2 but reads, in plain language, like an 8. What it can't do is know things the ticket doesn't say, which turns out to be most of what makes estimation hard in the first place. Treat it as a sanity check on your team's own estimates, not a replacement for making them.

What 'AI estimates story points' actually means

In practice, this means a model reads an issue's title and description, is given the team's recent history of similarly-worded issues and their assigned points, and returns a suggested number with a short explanation of why. It's not reasoning from first principles about the engineering effort involved — it's pattern-matching the new ticket's language against the team's own past sizing decisions. That's a meaningful distinction: the model is only as calibrated as the history it's shown, which means it inherits whatever inconsistency already exists in a team's estimates rather than correcting it.

What it's actually good at

The strongest use case is consistency at scale, on a backlog too large to eyeball. A model doesn't get tired grooming issue forty of sixty in a triage session the way a human does, and it applies the same standard to issue one and issue sixty, which a person drifting through a long grooming meeting genuinely doesn't. It's also well-suited to outlier detection: flagging 'this ticket is worded like the 8-point tickets you've shipped before, but someone sized it as a 2' is exactly the kind of pattern a model catches reliably and a human skimming a backlog easily misses. And for the routine majority of tickets — the ones that really are similar to twenty things the team's already estimated — a fast, roughly-right suggestion beats making someone stop and deliberate from scratch.

What it genuinely can't know

A ticket's text is not the work. It doesn't mention that the file it touches has no test coverage and everyone's scared of it, that the 'simple' API change actually requires coordinating with a team in another timezone, or that the last three tickets that looked like this one turned into a week each because of an undocumented quirk in a legacy service. That tacit knowledge lives in engineers' heads, not in ticket text, and no amount of reading comprehension recovers information that was never written down. A model returning a confident number on a vague ticket isn't confidently correct — it's confidently extrapolating from surface similarity to tickets that may not actually be similar underneath.

A concrete case where it helps and one where it doesn't

A ticket that reads 'add a "copy to clipboard" button next to the API key field' is the case where AI estimation earns its keep — it's genuinely similar to a dozen small UI-affordance tickets the team has already sized, and a model comparing it against that history will land close to what the team would've picked anyway, faster and more consistently than a five-minute planning-poker round for something this routine. A ticket that reads 'migrate the notification system to the new queue' is the case where it doesn't — the actual effort hinges on how tangled the existing notification code is, which the ticket's two sentences don't and can't describe, and a model will still return a confident-sounding number built entirely on how the words compare to past tickets, not on the tangle it can't see.

The honest verdict, and how it relates to not estimating at all

If your team has already moved to probabilistic forecasting from historical throughput instead of story points, this whole question is somewhat moot — you don't need points, so you don't need AI to guess them either; that approach sidesteps the estimation problem rather than automating it. If your team is committed to points for the foreseeable future — plenty of legitimate reasons to be, from stakeholder familiarity to fitting an existing process — AI estimation is worth using as a second opinion specifically because it's consistent and good at flagging outliers, not because it's more accurate than your engineers. The two approaches aren't in competition; they're answers for teams in different places.

A pattern that actually works

The version worth building is a suggestion, not a silent assignment: the model proposes a point value with its reasoning attached, the engineer who'd actually do the work confirms or overrides it, and — this is the part that makes it improve over time — overrides get tracked. A model whose suggestions get overridden constantly on a particular type of ticket is telling you something about a gap in what it's been shown, the same way a rising override rate on AI triage suggests something drifted and is worth a look. That's the same propose-and-approve shape that governs agent actions everywhere else in a workspace, applied here to a number instead of an action — because a wrong estimate silently baked into a sprint plan is exactly the kind of consequential mistake that shouldn't happen without a human in the loop. See how that discipline plays out across a whole sprint plan built with AI, estimates included.