Story points are one of those Agile practices that seem simple until people start using them like precision instruments.

Then suddenly a “5” becomes a contract, velocity becomes a performance metric, and someone is trying to calculate whether Steve is 23% more productive than Melissa based on Jira reports.

That’s usually the moment when the wheels start wobbling.

Story points are not supposed to be a tiny accounting system for human output. They’re a rough sizing tool. A way to help teams make slightly better guesses about uncertain work. Story points have two hopeful aspirations:

First, they can help you take a pile of work and roughly size it against a team’s capacity to approximate whether your goals and resources are aligned.

And yes, this is fuzzy math. Very fuzzy. By the time the gap is obvious, it’s often too late to hire your way out of it and see meaningful impact early enough. But it can still help reset expectations, adjust dates, reduce scope, and put useful pressure on the MVP conversation so the team ships something useful before the deadline turns into a post-mortem.

Second, story points also give the team a quick “finger-in-the-wind” test during refinement to see whether everyone is seeing the work roughly the same way. If everyone agrees that it is a 3, then we probably don’t need to spend more time talking about it right now. But if one person thinks it’s a 2 and another thinks it’s an 8, the number is not the interesting part. The conversation is. What are we seeing differently? Is there hidden complexity? Is the story too vague? How will we approach designing and building this at a high level?

And if the estimate turns out to be wildly inaccurate after doing the work, it’s a perfect seed to harvest in retro discussions! Going back and changing the original estimate does nothing other than hide the velocity dip in the metrics. (which… unfortunately… in some environments… is the actual goal)

The point of story points is not the points. It’s the conversations they trigger.