How story point estimation works
Story points measure the relative size of a piece of work rather than how long it will take. A team that estimates in hours is really estimating one person's speed on one day; a team that estimates in points is describing the work itself, which stays true regardless of who picks it up. Over a few sprints the team learns how many points it actually completes, and that number — velocity — becomes the basis for planning.
Size is not the same as difficulty. A task can be enormous and completely routine, like renaming a field across two hundred files, or tiny and genuinely risky, like changing one line in a payment processor. Good estimation holds both ideas at once, which is why this calculator asks about volume of work, complexity, and confidence separately instead of asking for a single gut number.
The eight factors
Six of the factors push the estimate up as they increase: business logic complexity, technical difficulty, amount of work, team collaboration, unknowns, and external dependencies. Two run the other way — familiarity with the task and clarity of requirements. Low confidence in either of those adds effort even when the work itself looks small, because the team will spend time discovering what it is actually building.
The factors are combined on a convex curve, so a story that is moderately hard in several dimensions scores higher than one that is severe in a single dimension and trivial elsewhere. That matches how work actually behaves: compounding uncertainty is worse than one known-hard problem. Three risk floors sit on top of the curve, because a story blocked on an unknown external dependency is never genuinely small no matter how tidy the rest looks.
Story points vs hours
The most common way to lose the value of points is to quietly convert them back into hours — "a point is half a day" — at which point you have hours with extra steps, and every problem that points were adopted to solve returns. Points work precisely because they are unitless and comparative. The question is never "how long is this?" but "is this bigger or smaller than that story we finished last sprint, and by roughly how much?"
Why Fibonacci?
The gaps in the Fibonacci sequence widen as the numbers grow: 1, 2, 3, 5, 8, 13, 21, 34. That shape encodes something true about estimating — confidence collapses as work gets bigger. Distinguishing a 1 from a 2 is a real judgement a team can make reliably. Distinguishing a 21 from a 22 is invented precision, so the scale simply does not offer the option. If a story lands on 34, the honest response is usually to split it rather than to estimate it more carefully.
Frequently asked questions
What are story points?
A relative measure of how much work a task involves, combining complexity, volume and uncertainty into one number so stories can be compared without committing to hours.
Are story points the same as hours?
No. Points measure relative size, not duration. Two teams can both call a story 5 points and deliver it in very different amounts of time.
What is a T-shirt size?
A coarser scale — XS through XXL — for teams that prefer a rough grouping to a number. This calculator shows both, so use whichever your team has adopted.
Who should estimate?
The people doing the work. An estimate handed down by someone else is a deadline wearing a costume, and it will not reflect what the team actually knows.
What if the team disagrees?
Disagreement is the useful part. A wide spread almost always means people are picturing different scopes, and the conversation that follows is worth more than the number.
Does this replace planning poker?
No — it gives a starting point. Use it to anchor the discussion, then let the team adjust. The shareable link exists so you can paste your reasoning into the ticket alongside the number.