Story Point Estimator

Story points are a relative size for the work in a user story. Instead of estimating in hours, your team agrees that a "1-point" story is a tiny change and an "8-point" story is much bigger — but how much bigger is calibrated to your team, not a clock. Two teams can have wildly different "8" sizes; that is fine, because each team only compares to its own history.

Fibonacci (1, 2, 3, 5, 8, 13, 21…) increases gaps between options as numbers grow. That stops false-precision arguments about whether a story is a 6 or 7 — at that size, the difference is below your team's ability to estimate accurately. It also signals more uncertainty for bigger numbers, which is honest.

Mark a few well-understood past stories as "reference" — a clearly small one (1 or 2), a clearly medium one (5), and a clearly large one (8 or 13). When estimating new work, ask: "Is this closer to the reference 5 or the reference 8?" Anchored estimates are far more consistent than absolute ones.

If a story scores 13 or higher, treat it as an epic in disguise. Stories that big almost always finish over the sprint boundary, getting cut in half by the calendar instead of the team. Split them before sprint planning into 1–8-point pieces.

It means the team does not know enough to estimate. Mark these and triage them in backlog refinement — typically the answer is "we need to talk to the customer" or "we need a spike to investigate." Estimating an unknown produces noise that polishes the entire team's velocity numbers.

Everything stays in your browser via localStorage. The estimator works offline and never sends data to a server. Use Export CSV to back up or share.