Planning poker alternatives that take five minutes, not forty

Scrumpy does not have a planning poker feature. No card deck, no vote timer, no reveal animation. It gets asked about, and the honest answer is that we decided against building it rather than never got round to it. So this post is us showing our working.

If you want the short version: the cheap replacements for planning poker are relative sizing against a reference story, triangulation with two references instead of one, silent affinity sorting when you have a big pile to get through, and asking the one or two people who will actually do the work. Most of them finish a backlog in the time a poker round takes to warm up.

But we should be fair to the thing we chose not to build, because it is better than its reputation.

What planning poker is actually for

James Grenning defined and named it in 2002, having decided that Wideband Delphi, the estimation method teams were reaching for at the time, took far too long. Mike Cohn then put it in front of most of the industry in Agile Estimating and Planning in 2005, which is why nearly every agile course now teaches it as the default.

The design is careful, and the careful part is the simultaneous reveal. Everyone commits to a number before anyone hears one, because the first number spoken out loud stops being an opinion and becomes a suggestion. That is anchoring, a well-documented cognitive bias, and hiding the cards genuinely defeats it.

The part people miss is what the cards are for after they turn over. The number is not the output. The spread is. If three people say 3 and one says 13, nobody is wrong: the four of you are picturing four different pieces of work, and you have just found that out for the price of one round. A wide spread almost always means the story is not understood yet, which is exactly the information you want before you commit a sprint to it. Averaging the votes to 5 and moving on throws away the only genuinely valuable thing that happened.

So planning poker is a disagreement detector wearing a card game costume. Judge it on that and it is a good piece of design.

We have recommended it ourselves, in as many words, in our own guide to story points: run a quick round, everyone reveals at once, the loudest voice stops setting the number. We would still say that to a newly formed team of six who do not yet know each other's judgement. We would not say it to four people who have shipped together for two years, and writing this post is what made us notice we had been giving both groups the same advice.

Then why does it stop paying on a four-person team?

Because on a small team with one clearly senior engineer, the reveal defeats the wrong anchor.

You hide the first number, everyone shows 3, 5, 5, 8, and then the discussion starts. And in the discussion the person who knows the codebase best explains why it is a 5, and it becomes a 5. The anchor did not arrive first, it arrived second, and the cards have no defence against that one. Which is not planning poker's fault. It was built for a room of peers, and a four-person team with a dev lead and a junior is not that room.

Watch your own last three sessions and one of two things is true. Either the votes basically agree every time, in which case the meeting is a formality and you could get the same numbers by asking, or they diverge and then converge on whatever the senior dev said, in which case you are running a forty-minute ceremony to reach a decision one person is making anyway.

Then do the arithmetic on it. Forty minutes, four people, twenty-six sprints a year: sixty-nine person-hours, close to two working weeks of your team's year, spent on a signal you could get more cheaply. Estimation is overhead. Useful overhead, but overhead, and overhead should be sized to the risk it removes.

Relative sizing against a reference story

This is the cheapest thing that works, and if you only take one method from this post, take this one.

Pick a story your team finished recently that everybody actually remembers touching. Not a hypothetical, not something from the archive. Agree that it is a 3. Now every new story gets sized by one question: is this bigger than that, smaller, or about the same? Most answers arrive in under ten seconds, because you are not estimating, you are comparing, and humans are far better at comparison than at measurement. That is the same reason story points beat hours in the first place.

The reference story has to be shared and it has to be recent. A reference from eight months ago, in code nobody has opened since, quietly rots and takes the whole scale down with it. Replace it every couple of months with something fresher.

Triangulation, which is one reference more than most teams use

One anchor gets you a rough scale. Two anchors get you a calibrated one.

Keep a small reference, say the 3, and add a large one, say an 8. Now a story is not just "bigger than the 3", it is "bigger than the 3 and clearly smaller than the 8", which forces it to land at a 5 rather than drifting wherever it fancies. Teams working from a single anchor tend to compress everything toward the middle of the scale, and a second reference at the top end is the fix.

This is also the fastest way to catch inflation. If a story that feels the same size as your 3 keeps getting called a 5, you have not got harder work, you have got a slipping scale, and your velocity number will drift upward while nothing real changes.

Silent affinity sorting, for when the pile is large

Facing forty unestimated items, no method that spends two minutes per story is viable. Affinity sorting handles the volume by removing the talking.

Put the items on a wall or a shared canvas, left to right, smallest to largest. Everyone moves cards at the same time, in silence, no explanation offered or requested. If you disagree with a placement you just move it. After about ten minutes the wall has settled, and the only items still moving are the ones that need conversation. Draw your buckets across the row, assign points per bucket, and you have sized forty stories in the time it takes to poker four.

The interesting part is what the silence produces: the same disagreement signal as the cards, expressed as a card that keeps getting dragged back and forth. Anything moved three times is your 13, whatever number ends up on it.

Or just ask the two people who will do the work

This is the one that makes agile coaches wince, so here is the case for it.

An estimate is only worth the knowledge behind it. On a four-person team, a story about the billing integration is going to be done by one of the two people who understand billing, and their sized guess is more accurate than a consensus that averages in two people who have never opened that code. Asking them takes ninety seconds. Getting the whole team to vote on it takes ten minutes and produces a number that is, at best, the same.

Where this fails is real and worth naming. Accuracy was never the only reason to estimate as a team. It is also how knowledge gets spread, and the round where the junior asks why this is an 8 is often the most useful five minutes of the sprint. Lean on the two-person shortcut for everything and you optimise your Tuesday and slowly build a team where two people own the risky parts of the system and nobody else can help. Use it for routine work in well-trodden code, not for the things you would be nervous to have one person carry alone.

That is the honest trade, and it is a trade, not a free win.

When to reach back for the full cards

Planning poker is not retired, it is on call. Bring it back when the situation actually contains the uncertainty it is designed to expose:

• A story in unfamiliar territory: a new integration, a part of the system nobody has touched, anything where "we think we know" is doing a lot of work.
• A new joiner, or two, who need to calibrate their sense of a 5 against everyone else's. A couple of rounds does this faster than a month of osmosis.
• A story you can already feel the room disagreeing about. If two people have talked past each other twice, stop arguing and reveal numbers.
• Anything with real money or a real external date attached, where being wrong costs more than the meeting does.

Notice what these have in common. Every one of them is a case where you expect a wide spread. That is the trigger. If you can confidently predict everyone will show the same card, you already have your estimate and the ceremony is a re-enactment.

What we built instead, and the bit we are uneasy about

In Scrumpy, points are a plain field on the story. Each team defines its own scale in team settings, defaulting to 1, 2, 3, 5, 8, 13, up to ten values of your choosing if Fibonacci is not your religion. There is no zero: the smallest allowed value is 1, and a story with no estimate reads "Not estimated" rather than pretending zero is a size. Switch sprints off to run a continuous board and the points field disappears from the story altogether, because sizing work you are not committing to a sprint is a hobby.

Sizes then feed the sprint commitment directly. Each sprint row shows its committed points against your rolling velocity, averaged over the last five completed sprints, and the little bar tips amber once you pass that number and red about ten percent beyond it. That is the only place we think an estimate has a right to nag you.

Here is the part we are less comfortable with. Scrumpy's AI assistant will suggest a point value for a story, chosen from your own scale, offered in a dialog you either apply or discard, and it returns "No confident suggestions for this story" rather than guessing when the story is too thin to judge. It is included in the plan with no separate AI bill, metered against a monthly fair-use allowance, and it only ever runs when someone clicks it.

We are aware of the irony. Planning poker exists to stop a number arriving before the thinking does, and we shipped a button that produces a number before the thinking arrives. Our defence is thin but real: the suggestion is aimed at the fifty stories in the backlog that will otherwise sit unestimated forever, not at the six stories you are about to commit to. For those six, argue. The tool should not have an opinion about work you have not read yet, and neither should you.

What we did not want to build was a meeting. A card-voting mode would be a feature that only pays off if you gather four people at the same time every fortnight, and we do not think most four-person teams should be doing that. Building it would have been us endorsing the calendar invite.

What to do next sprint

Skip the poker round once. Pick your reference story before the meeting starts, size the backlog by comparison, and see how long it takes. Our guess is under ten minutes, and that the numbers land within a point of where the cards would have put them. If they do not, if the room splits and the comparison method cannot settle it, you have learned something worth knowing: those are exactly the stories that deserve the full ritual, and now you know which ones they are.

The rest of what the poker round was doing was refinement, and refinement is better done in small doses through the sprint than in one long sitting with a deck of cards. Get the sizing out of the way early and sprint planning turns back into the conversation it was supposed to be: what are we actually trying to finish, and can we?