Story points: what they measure, and how to use them well
Story points give a team a shared, relative way to size work without pretending to predict exact hours. Used well, they surface hidden complexity and uncertainty through discussion. Used poorly - as a stand-in for hours, a productivity score, or a way to compare teams - they create false precision and bad incentives. This guide covers what points measure, how to pick a scale, and how to calibrate a team over several sprints.
A story point is a relative measure of the effort, complexity, and uncertainty in a piece of work, sized against other work the same team has already estimated. A 5 is not "5 hours" or "5 units of some universal difficulty" - it means "about as much effort and uncertainty as the other things this team has called a 5."
Because points are relative to one team's own history, they are not a productivity score, not a currency for negotiating deadlines, and not a number that means the same thing on a different team. Two teams can both size a login page as a 3 and still take very different amounts of calendar time to build it - the estimate was never meant to travel between teams.
Story points are also a popular community practice, not something Scrum itself specifies. The current Scrum Guide describes sizing backlog items as part of ongoing refinement but does not name story points, Fibonacci, or planning poker as required techniques - teams are free to use points, T-shirt sizes, or flow-based forecasting instead, as long as the team agrees on one approach and applies it consistently.
Choosing a scale: Fibonacci, T-shirt sizes, and more
No estimation scale is universally correct. Each one trades off precision, speed, and the kind of conversation it produces, and the right choice depends on your team's habits more than on any inherent property of the scale itself.
Fibonacci-style scales (1, 2, 3, 5, 8, 13...) widen the gaps between values as size grows, which discourages arguing over whether something is an 8 or a 9. T-shirt sizes (XS-XL) suit rough, early sizing before a backlog item is fully understood. Powers of two (1, 2, 4, 8, 16...) give a similar widening-gap effect with simpler mental math. Custom decks let a team drop values it never uses or add ones specific to its own work.
SprintBee ships six built-in decks: Fibonacci, a modified Fibonacci deck (0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100) as the room default, T-shirt sizes, powers of two, a plain sequential 1-10 scale, and an hours-based scale for teams that plan directly in time. Every deck can also be edited - add, remove, or reorder values, up to 15 cards each - plus quick-add cards for "?" (need more information), "∞" (too big to size responsibly), and "Pass."
Say a team has already completed two similar items: a small settings toggle it called a 2, and a medium-sized form-validation change it called a 5. A new item - adding a field to an existing form, including validation and a small database migration - clearly needs more care than the toggle but doesn't feel unusually large or risky. The team isn't asking "how many hours will this take," it's asking "is this closer to the 2, closer to the 5, or beyond both."
Votes across the team don't need to match to be useful. If most of the team votes 5 but one person votes 13, that difference is the point of the exercise: it usually means that person is aware of a dependency, a migration risk, or a testing cost the rest of the team hasn't considered yet. Reveal-then-discuss formats like planning poker exist specifically to surface that kind of information before the item enters a sprint, rather than to force everyone toward the same number.
A wider split makes the same point more clearly. Votes of 3, 5, 8, and 13 on one item aren't a failed round - they're four different mental models of the same work. The team asks the 3 what they assumed was out of scope, asks the 13 what risk they saw, and often converges on a 5 or an 8 once that assumption surfaces, rather than by simply averaging the four numbers together.
Most of the value teams lose from story points comes from a small set of repeated mistakes, not from picking the wrong scale.
Converting points to hours. A point value only means something relative to other estimates from the same team; treating "a 5" as "roughly two days" erases the uncertainty the point was meant to express and quietly turns an estimate into a deadline.
Turning velocity into a target. Velocity is a forecasting input for one team's own near-term capacity planning, not a productivity score. A goal like "increase velocity 20% this quarter" pressures teams to inflate estimates rather than deliver more, which makes the number useless for its original purpose.
Chasing false precision. Debating whether something is an 8 or a 13 usually means the scale is being asked to do more work than it can. If a team can't converge within a round or two of discussion, that's a signal to split the item or gather more information, not to negotiate the exact number.
Comparing points across teams. Because each team calibrates its scale against its own history, "Team A finished 80 points, Team B finished 50" says nothing about who did more work. Cross-team velocity comparisons are one of the most common ways story points get misused.
Calibrating a team over several sprints
A team's first few sprints of estimates will be noisy, and that's expected - the scale only becomes useful once the team has a shared set of reference stories to compare new work against. Rather than trying to get every estimate exactly right immediately, treat the first several sprints as calibration: estimate, deliver, and then compare the estimate to how the work actually went.
A short conversation after each sprint - did the 3s feel like 3s, did anything sized small turn out to hide real complexity - builds the shared reference points that make future estimates faster and more consistent. Reviewing a history of completed items next to their accepted estimates makes that comparison concrete instead of relying on memory; SprintBee keeps a history of completed rounds within the current session and can export it to CSV, and paid plans can also reopen and browse past sessions to compare estimates across a run of sprints.
Calibration is a team activity, not an individual one. The goal is a shared sense of scale within the team, not agreement with any other team's numbers - estimates only pay off once they feed honestly into the sprint's capacity and commitments.
