Story Point Cheat Sheet
A dense, one-page reference for a team that already knows the theory and just wants the numbers, the scale, and the common failure modes in one place. For the full explanation behind any of this, see the complete story points guide.
The scale
| Points | Meaning | Typical example |
|---|---|---|
| 0 | Trivial, barely worth logging | Fix a typo, bump a config value |
| 1 | Tiny, fully understood | Add one validation rule |
| 2 | Small, clear path | A straightforward CRUD field |
| 3 | Solid, still clear | A new form with a few states |
| 5 | Meaningful size or complexity | A new API integration with known docs |
| 8 | Large - worth watching | Touches several systems, real unknowns |
| 13 | Near the ceiling | Should usually be split before a sprint |
| ? | Not estimable yet | Spike it or split it |
Full rationale for why the gaps widen: Fibonacci story points explained.
Baseline reference examples per size
Concrete anchors help more than the abstract table above. Adapt these to your own codebase, but the pattern generalizes:
- 1-2: a config change, a copy update, a single new validation rule, a straightforward bug fix with a known cause.
- 3: a new form field with basic validation, a small new API endpoint with an existing pattern to follow, a well-scoped UI component.
- 5: a new page or flow with a couple of states, an integration with a well-documented third-party API, a moderate refactor confined to one module.
- 8: a feature spanning multiple screens or services, an integration with an unfamiliar or poorly-documented API, a change that touches shared infrastructure.
- 13: rare in a healthy sprint - usually a sign the story should have been split during refinement.
The rules, compressed
- Vote in private, reveal at the same time. Never speak an opinion before the vote - it anchors the room.
- Wide spread → the highest and lowest voters explain first, then re-vote once.
- Still split after two rounds → the story isn't ready. Park it, don't average it.
- Points measure relative effort, not hours. No per-story conversion rate exists - see why not.
- Points are calibrated to one team's own history. Never compare point values across teams.
- The Product Owner clarifies scope; they don't vote.
Full mechanics: the Scrum Poker guide.
Conversion anti-patterns (don't do these)
- "1 point = 4 hours." Any fixed hourly rate reintroduces the false precision points exist to remove.
- Comparing a "5" on Team A to a "5" on Team B. Different teams, different calibration, same-looking number - meaningless comparison.
- Re-estimating a carried story just because it's taking longer. Scope hasn't changed, so the estimate shouldn't either - see when to re-estimate mid-sprint.
- Treating the estimate as a delivery promise. Estimates are forecasts, not commitments; conflating them causes padding and dishonest voting.
- Estimating a story with no acceptance criteria. Produces a wide spread that looks like disagreement but is actually everyone estimating a different imaginary story.
Who votes: compressed
| Role | Votes? |
|---|---|
| Developers, QA, anyone building/verifying the work | Yes |
| Product Owner | No - clarifies scope, doesn't vote |
| Non-technical stakeholders | No - answers questions only |
| Designers | Depends - agree on the dimension being estimated first |
| Spectators | No - watch without affecting the round |
Full etiquette per role: who should be in the room.
Team size cheat sheet
- 2-3 people: fast convergence, but watch for shared blind spots - compensate with more frequent calibration checks.
- 4-7 people: the generally cited sweet spot for real disagreement without chaos.
- 8+ people: junior voices start anchoring to senior ones before the reveal even happens. Enforce simultaneous reveal strictly, and treat outlier votes as valuable signal to protect against groupthink.
Full guidance: how team size affects estimation accuracy.
Quick reference: velocity math
Average velocity = sum of points completed over the last 3-4 sprints ÷ number of sprints.
Rough forecast = remaining backlog points ÷ average velocity = sprints needed. Always state this as a range (velocity swings roughly ±25% sprint to sprint), never a single decimal number. The story-points-to-hours converter does this math and gives you the range automatically.
Capacity for a specific sprint = (team size × working days − planned days off) × focus factor (usually 70-80%). The sprint capacity calculator runs this for you.
Need a starting number fast?
The story point calculator turns three quick ratings - complexity, volume, uncertainty - into a suggested starting card, with honest guidance for when the right answer is "spike this" instead of a number. Use it before a session to form your own view, then bring it to the team vote.