Picture a refinement call. The team pulls up a story, everyone votes, and the cards come back 3, 3, 5, 8. Before anyone can ask the developer who threw the 8 what she saw that the others didn't, the product owner cuts in: "Let's call it a 5. That's about two days, right?"
That question is where story points quietly stop working. Not because the product owner is wrong to want a date. Dates are a legitimate need. It stops working because the moment a 5 means two days, you no longer have story points. You have hours wearing a costume, and the costume does nothing except make the hours harder to read.
What a point actually bundles together
A story point compresses three things into one number: how much work there is, how tangled that work is, and how much you don't know yet. Effort, complexity, uncertainty. A story can be big and boring (rename a field across forty templates), small and gnarly (fix a race condition that shows up once a week), or trivial to build and terrifying to get wrong (touch the payment retry logic). Points let you weigh all of that at once without pretending you can separate the strands.
And they're relative. A 5 means nothing on its own. It means "bigger than our 3s, smaller than our 8s." That's the whole trick. Humans are mediocre at absolute estimation and consistently decent at comparison. Ask me how many hours a feature will take and I'll be wrong by a factor of two in either direction. Ask me whether it's bigger than the last one we shipped and I'll usually be right.
Which is why the number itself is the least valuable output of an estimation session. The value is the argument. When four people size a story as a 3 and one sizes it an 8, you haven't found a disagreement about numbers. You've found two different stories hiding under one title. The 8 knows something, or fears something, and the ten minutes you spend finding out are worth more than any figure you write on the ticket.
A worked example: sizing against a known 3
Say your team's shared reference for a 3 is "add a sort dropdown to the invoice list." Everyone remembers it: familiar code, one fiddly edge case with archived invoices, finished without surprises.
Now you pick up "send a password reset email." It sounds smaller than the dropdown. It's one email. Then you talk it through. Someone mentions token generation and expiry. Someone asks what happens when a user requests three resets in one minute. The copy needs translating because the app ships in four languages. And nobody has touched the transactional mail setup since a contractor configured it two years ago.
Is it more effort than the dropdown? A bit. More complex? Somewhat. More uncertain? Massively, because of that untouched mail configuration. So it lands at an 8. Not because anyone computed hours, but because next to the known 3 it's clearly bigger, and hazier by another step on top of that. The uncertainty did most of the lifting here, which is exactly what points are for and exactly what an hours estimate would have flattened.
Why teams drift back into hours anyway
Nobody decides to corrupt their points. It happens by erosion.
Management pressure is the usual start. Someone above the team needs a date for a customer or a board deck, asks what a point "translates to," and gets a helpful answer like "roughly half a day." That conversion gets written down on a wiki page. From then on, every estimate is silently divided into days before it's spoken aloud, and people start sizing to hit the date rather than to describe the work.
Capacity planning does the same job more politely. A spreadsheet wants to know how many points fit into a sprint with two people on leave, and the cleanest way to make the spreadsheet work is to treat points as hours with a scaling factor.
And tooling nudges you constantly. Plenty of issue trackers put an hours field right next to the points field, or report "estimated time" computed from points behind your back. Defaults shape behavior more than policies do.
Here's the honest part: if your context genuinely needs time estimates, use time estimates. Short-cycle support work, contract billing, a two-person team that talks all day anyway. There are real cases, and I've written about where each approach earns its keep in story points vs hours. What doesn't work is running hours in secret behind a points facade. You pay the ceremony cost of points and get none of the benefit.
Velocity is a weather report, not a scoreboard
Used well, velocity answers one small question: roughly how much should we pull into the next sprint? A rolling average over the last few sprints, treated as a range rather than a promise, is genuinely useful. It's a weather report. You dress for it. You don't take credit for it.
The trouble starts when velocity becomes a performance metric. Goodhart's law applies with brutal reliability: when a measure becomes a target, it stops measuring anything. Tell a team their velocity should go up and it will go up, immediately and forever, because the team controls both sides of the equation. Yesterday's 3 becomes today's 5. The chart climbs, throughput doesn't move, and, worse, the planning signal you actually needed is now noise. You traded a working forecast for a flattering graph.
Cross-team comparison is the same mistake wearing a suit. Team A's 40 points per sprint versus Team B's 25 tells you nothing, because a point is a unit each team invented for itself against its own reference stories. It's comparing my miles to your kilometers, except neither of us wrote down a conversion. If you're a scrum master and someone builds a dashboard ranking teams by velocity, that's worth spending political capital to kill. Politely. But kill it.
How a new team calibrates
A team with no history has no ruler yet, so build one deliberately.
Pick three to five recently finished pieces of work that everyone remembers, spread across sizes: something small, something medium, something that hurt. Agree on what each would have scored and pin those as reference stories. From then on, every new story gets triangulated instead of sized from scratch. Bigger than the 2? Smaller than the 8? About the same as that reporting fix? You're never asking "how big is this," only "what is this most like," which is the question people can actually answer.
Estimate independently and reveal simultaneously, because the first number spoken out loud anchors everyone who hasn't voted yet. That's the entire reason planning poker exists as a format, and it's why we built a free planning poker room into ScrumMastr rather than treating it as a paid add-on. The mechanics matter less than the rule: nobody sees anyone else's number until everyone has committed.
Expect the first three or four sprints to be noisy. That's not failure, that's calibration. The ruler gets straighter every time the team compares an estimate to what actually happened and argues about the gap.
Don't re-estimate finished work
Every few months someone proposes going back and correcting the estimates on completed stories so the velocity data is "accurate." Skip it. The estimate already did its only job, which was to help you plan before the work started. Changing it afterward improves nothing you'll ever decide with, and it teaches the team that numbers get rewritten when reality disagrees, which is exactly backwards.
The useful version of that instinct belongs in the retro. If you're surprised in the same direction over and over (everything touching the billing service runs long, say), talk about it and let it move your next estimates. Learn forward. Leave the history alone.
When a big number means "split this"
Every scale has a threshold where the number stops being a size and becomes a message. For most teams that's the 13, or the 20 if you use one. A story sized that large isn't a large story. It's several stories that haven't been separated yet, plus a pile of unknowns nobody has named.
Treat it that way. Don't argue about whether it's a 13 or a 20; that's debating the length of a coastline. Split it, or cut a short timeboxed spike to shrink the biggest unknown, then size what's left. Does the exact threshold vary by team? Sure. Whether the threshold exists doesn't.
Keep the number cheap
One last piece of advice: guard the cost of estimation itself. Points work because they're fast and approximate. The moment your team spends twenty minutes arguing over whether something is a 5 or an 8, the number has become more expensive than it's worth. Take the shortest useful path instead: pick the higher number and move on, or split the story, or name the disagreement and schedule a spike.
A story point is a unit your team made up so it could have better conversations about work it doesn't fully understand yet. That's all it measures: your team's shared, calibrated sense of relative effort and risk. Everything that goes wrong with points comes from asking the number to be something sturdier than that. Keep it cheap, keep it relative, keep it inside the team, and it will keep being useful.