Story point estimator
A shared definition of what 1, 2, 3, 5, 8 and 13 points actually mean, and a calculator that turns a sized backlog into working days including regression. The reference table is the half most teams skip, and it's the half that makes estimates comparable between people.
What each size means
Points measure effort, risk, repetition and complexity together, not hours. The time column is a sanity check, not a conversion rate.
| Points | Effort | Typical time | Risk | Complexity & uncertainty |
|---|---|---|---|---|
| 1 | Very low | Minutes to an hour | Minimal | Straightforward task with clear requirements and no expected challenges. |
| 2 | Low | Half a day | Low | More involved than a 1-pointer but still routine. Minor uncertainties, predictable outcomes. |
| 3 | Moderate | One day | Moderate | Moderately complex, multiple steps, some dependencies that could affect completion. |
| 5 | High | More than a day | High | Complex work needing considerable time and resources, with notable uncertainty and room for surprises. |
| 8 | Very high | About a week | Very high | Considerable complexity, often several people involved. Significant unknowns and a high chance of change during testing. |
| 13 | Extremely high | More than a week | Extremely high | Highly complex, needs extensive coordination. Many unknowns and a high probability of scope change. Split it. |
Scroll for more columns
Turn a sized backlog into days
Ticket count by size (dev + QA)
| Points | Tickets | Days each | Days |
|---|---|---|---|
| 1 | 0 | ||
| 2 | 0 | ||
| 3 | 0 | ||
| 5 | 0 | ||
| 8 | 0 | ||
| 13 | 0 |
Scroll for more columns
Total estimate
-
The days column is editable. Derive your own numbers from finished tickets rather than inheriting mine - every team's point-to-day ratio is different, and that's fine as long as it's consistent.
Points measure size, not hours
The moment a team agrees that "3 points = one day", points stop being useful and become hours with extra steps. What makes the scale work is that it captures four things at once: effort, risk, repetition and complexity. A one-day task the team has done fifty times is not the same size as a one-day task nobody has attempted, and points can express that difference where hours cannot.
Estimate relatively, then convert once. Size tickets against each other in refinement, with no clock in the room. Convert to days later, at the backlog level, using your own historical ratio. That's what the calculator above is for, and it's why the conversion lives outside the sizing conversation.
The gaps in the sequence are the point. 1, 2, 3, 5, 8, 13 grows fast on purpose. The bigger a thing is, the less precisely anyone can size it, so the scale stops offering precision it can't deliver. Arguing between 5 and 8 is useful; arguing between 8 and 9 is theatre.
Everything at 13 is a research task in disguise. A 13 is the team saying "we don't understand this yet". Split it, or spike it first and size the pieces afterwards. Committing to a date that contains a 13 is committing to a number nobody in the room believes.
Include QA in the ticket, not after it. The count above is dev plus QA deliberately. Sizing development alone and treating testing as free is the most common reason sprint estimates come in optimistic by roughly a third.
Regression is a fixed cost, not a rounding error. Whatever the release contains, someone has to check the things it might have broken. Budget it explicitly - buried in the tickets, it silently eats the buffer you thought you had.