Choosing a Planning Poker Scale

The deck a team estimates with is not a cosmetic choice. It determines how precise people feel entitled to be, and precision is exactly the thing estimation should not encourage. A scale with evenly spaced values invites debate over adjacent numbers, because the gap between 6 and 7 looks like a real distinction. A scale with widening gaps makes that debate impossible to have — there is no value between 8 and 13, so the team is forced to pick a bucket and move on. That constraint is the point. Most of the difference between scales comes down to how quickly the gaps widen and whether the values look like numbers you could add up. Everything below follows from those two properties.

The default, and the right default for most teams doing sprint-level estimation. Each value is roughly 1.6 times the one before, so the proportional gap stays constant while the absolute gap grows. That matches how estimation uncertainty actually behaves: you can tell a 1 from a 2, but nobody can honestly distinguish a 13 from a 15. Use it when the team is estimating stories that will be delivered inside a sprint and wants a velocity number that means something. Watch out for the temptation to treat the top of the scale as a real estimate. A 21 is usually the team saying “we do not understand this yet”, and it should trigger a split rather than a commitment.

The same curve with more resolution at the bottom and rounder numbers at the top. The 0 and ½ cards matter more than they look: without them, a team with genuinely trivial work inflates it to a 1, and the 1 stops meaning anything. The high end trades Fibonacci's 21 and 34 for 20, 40 and 100, which reads better to stakeholders and quietly signals that these are magnitudes rather than estimates. Use it when your backlog regularly contains near-zero items — config changes, copy tweaks, one-line fixes — alongside substantial features, or when you estimate epics on the same scale as stories.

Relative sizing with the numbers removed. The absence of arithmetic is the feature: nobody can add six mediums together and present the total as a plan, which makes T-shirts hard to abuse. Use it when you are sizing epics for a roadmap, estimating a quarter of work before anything is refined, or introducing estimation to a team that keeps sliding back into hours. Removing the numbers removes the temptation. Watch out for the fact that you cannot compute velocity from it. Teams commonly map sizes back to points for planning — S=2, M=3, L=5 — at which point you have Fibonacci with extra steps, and you may as well estimate in points directly.

The most aggressive of the common scales: every value is exactly double the last. The only question the team can answer is “is this about the same, or about twice as much?” Use it when sessions are running long and the team is losing time to hair-splitting. The wide gaps make estimation fast and decisive by removing the option of being precise. Watch out for systematic rounding. When the real answer is between a 4 and an 8, teams tend to pick the lower value, and over a sprint that bias adds up to a meaningful under-estimate.

Evenly spaced values, which feel intuitive and are usually a mistake. A linear deck says that the difference between 1 and 2 is the same kind of difference as between 8 and 9, which is false: the first is a real distinction and the second is noise. The predictable result is long arguments over adjacent numbers that change nothing about what gets built. Use it when a team genuinely cannot get on with Fibonacci gaps and you would rather have them estimating than arguing about the deck — then move them across once relative sizing feels natural.

A different axis entirely: instead of sizing human effort, the team sizes the compute a task will consume. The values follow roughly the same widening curve as Fibonacci, for the same reason. The property that makes tokens unusual is that they add up to something real. Story points are ordinal — a sprint total is only comparable to that team's other sprint totals — whereas a sprint's tokens multiplied by your rate per million is an actual number of pounds or dollars. Use it when agents do a substantial share of the implementation and the interesting constraint is budget rather than capacity. Most teams that adopt it run it alongside points rather than instead of them.

Sometimes none of the standard decks fits — a team estimating support tickets by response class, or one that wants explicit cards for states the standard scales cannot express. A custom deck lets the host supply whatever values the team actually reasons in. Two cards are worth adding to almost any deck regardless of scale. A question mark means “I cannot estimate this with what I know”, which is real information and should stop the round rather than being rounded to a number. And a coffee cup, or whatever your team calls it, means “I need a break” — trivial, but it stops people voting badly because they have been in the session for fifty minutes. The constraint on custom decks is discipline: keep the gaps widening. A custom deck of 1 through 20 is a linear scale with extra work.

Changing scale mid-project invalidates the velocity average, because the units change underneath it. That is a real cost, but it is a one-off cost and usually worth paying if the current deck is not working. The cleanest approach is to switch at a sprint boundary, re-anchor with two or three reference stories in the new deck before estimating anything new, and treat the next three sprints as recalibration with no reliable forecast. Resist converting the old velocity with a multiplier — the mapping is never linear, and a converted number carries false authority. Switching mid-session is a different matter: any votes already cast are in the old units and are meaningless in the new deck, so they have to be cleared and the round re-run. Scrum Points does this automatically when the host changes the scale, which is the behaviour you want — a silently retained vote in the wrong units is worse than no vote.