Story points don't predikt your sprint. They end the meeting.
Nobody believed the only engineer who was right.
Somewhere on your team's board right now there's a ticket marked 3 that everyone quietly knows is a 5, and a 5 that one engineer swears is an 8. She said so in the estimation meeting. She got outvoted. In three weeks, when the sprint slips, the retro will call it a scoping surprise, and nobody in the room will say the true thing out loud: she was right, the vote was wrong, and the number on the ticket recorded the argument instead of the work. That's what a story point is. A record of an argument. The team debates, someone anchors the range by speaking first, the outliers get asked to defend themselves, and the group converges on a number everyone can live with. Whether the work takes two days or two weeks is a separate question the number never touched, because nobody had done the work yet, and the one person who could see the buried complexity is exactly the person the process is built to average away.
Two forces do most of the damage in that meeting. Whoever gives the first number sets the range, and everything after is haggling around the opening bid; auction houses have run on this for centuries, and estimation meetings rediscover it every other Tuesday. And the engineer who knows the codebase best usually estimates highest, since she's the only one who can see the migration hiding under the feature. The room can't see it, so her honesty reads as pessimism, and the average wins. The average always wins. That's what averaging is.
So here's a bet. Export your last couple quarters of finished tickets with their point values and their actual cycle times. Group by points, then look at the spread inside each group. I'd bet money your 3s and 5s overlap so heavily that the labels barely separate, and that at least one of your 5s finished before one of your 2s. The whole export takes twenty minutes. If your histogram shows clean separation between point values, reply with it and I'll publish it with an apology attached. If it doesn't, you've just watched your estimation process fail an audit it didn't know it was taking.
The standard defense is half right, and the half matters. Points were never supposed to be accurate, people say; they exist to force the conversation. True. The conversation is worth having. The hidden migration surfaces, the guy who skimmed the ticket rereads it, assumptions get said out loud. But every one of those benefits comes from the talking, and none comes from the number the talking produces. Then somebody sums the numbers into velocity, charts the velocity, plans the quarter against the chart, and reviews people against the plan. A figure the whole team agreed was a rough conversational aid got promoted into a performance metric, and there was never a meeting where anyone decided that on purpose.
The replacement costs nothing. Keep the discussion, drop the sizing question, and ask two things instead: what does this ticket depend on, and what about it do we not know yet. "This touches the auth service and we've never load-tested it" is a fact you can act on today, which is more than you can say for a 5. For forecasting, count finished tickets. Over anything longer than a sprint, plain throughput predicts about as well as velocity, and nobody can game it by inflating estimates, which is the other thing every team does and no team admits.
Story points survive because they let three groups of people stop worrying at the same moment. Engineers get to end the meeting. PMs get a number for the plan. Leadership gets a chart that goes up. That's a real service, and it has almost nothing to do with when the software ships.
The bet stands. Twenty minutes and either I owe you a public apology or your velocity chart owes your team one. And if you want to skip the estimation debate entirely, Prdikt converts your requirements into sprint-ready plans automatically, no story points required. Try it at prdikt.com.
