Photo by Ivan S
“Is this a 1 or a 2?”
“It’s not a 2, it won’t take 2 days.”
“Oh, 2 points is about 1 day. 1 point is half a day.”
“Ah okay… then this is a 1.”
I’ve heard a conversation like this more than once. Somewhere along the way, story points have quietly become time estimates.
I still remember how I was first introduced to estimation. I was given a simple task and was told to estimate in terms of effort, complexity and uncertainty. I was a newbie and confused at first because my team lead could probably finish the task much faster than I could, but my manager assured me that was completely acceptable. Story points are not a measure of time I take to complete a task.
Humans are actually quite poor at precise estimation, especially when uncertainty is involved. But we are surprisingly good at comparison. We may not know exactly how long something will take, but we are usually able to tell when a task feels smaller than another, riskier, has more unknowns or probably twice as complex. That is the purpose of relative estimation.
Then why Fibonacci, I asked. I was told that the increasing gaps between the numbers are intentional. A team can usually tell the difference between a 1-point and a 2-point task. But as the problem gets more complicated, uncertainties increase and over-precise estimation becomes risky. Trying to distinguish between 8 and 9 creates an illusion of accuracy around a task already filled with unknowns.
I realised many teams slowly drift toward treating story points like calendar units. If 1 point takes half a day and 2 points take one day, do you take three days to complete a 5-point story?
At first, this feels efficient. At least it helps the team arrive at numbers quickly. But over time, we stop asking how complex or uncertain a task is. We ask instead, how quickly can he or she finish this. And those are not the same question.
Recently, another question started forming in my head as more software teams, including mine, began adopting AI tools into the development workflow.
If AI helps us build faster, should story points shrink too?
At first glance, the answer feels obvious. If a task that previously felt like a 5-point story can now be completed much faster with AI assistance, shouldn’t it become a 2 or a 3 instead? But the more I thought about it, the more familiar it started to sound - “2 points means one day”.
A developer may now write certain parts of the code faster, but that does not necessarily mean the story itself has become simpler, less risky, or less uncertain.
So the line of distinction becomes this:
AI may affect velocity, but not estimation itself.
Story points describe relative effort, complexity, and uncertainty. Velocity describes how much a team can deliver over time. AI may improve the second dramatically without fundamentally changing the first.
It may increase how much a team can deliver in a sprint, but that does not necessarily mean the stories themselves become “smaller”.
Ironically, AI made me appreciate the original purpose of story points even more. They were never meant to measure how fast we can write code anyway.