Planning poker for 2 people

The standard format assumes a distribution. With five voters you get a cluster and one or two cards sitting away from it, and the useful conversation is the gap between them. Two voters produce no cluster. Either you match, in which case there was nothing to discuss, or you differ, in which case the split is 50/50 and both of you are the outlier.

That collapses the step most teams treat as the heart of the session. “Let’s hear from the high card and the low card” is a way of narrowing a room down to the two people who disagree. In a pair you are already there, so the instruction does no work.

The bigger problem is convergence. Larger teams resolve a stubborn split by weight of numbers: after the second round the strays usually join the majority, and if they do not, the majority carries. A pair has no majority and therefore no natural stopping point. Two rounds of re-voting where neither person moves is a loop, and the usual escape from it — splitting the difference — is worse here than anywhere else. A 3 and an 8 do not make a 5.5, and with only two opinions in the room that midpoint carries no information at all.

Strip planning poker back and one mechanism is doing nearly all the work: everybody commits privately and the cards turn over together. That mechanism is not less valuable in a pair. It is more valuable, because a pair is the situation where anchoring is hardest to resist.

Two people sizing a ticket in conversation is a sequence, and whoever speaks first sets the range. If that person is the tech lead and the other is three months into the job, the second estimate is not really an estimate. It is agreement with a number, offered by someone with every social reason to agree. There is no third voice to notice the deference and no distribution to make it visible afterwards.

Simultaneous reveal removes the sequence. The junior developer’s 8 exists before the lead’s 3 is visible, and once it is on the table it has to be argued down rather than never spoken. That single change is worth keeping even when everything else about the ceremony is dropped.

Treat any gap wider than one card as a mandatory discussion. On a Fibonacci deck, 3 against 5 is one step and usually means you agree about the work and disagree about rounding. 3 against 8 is two steps and means one of you knows something the other does not. The first is a rounding decision, the second is always worth five minutes.

Agree in advance to take the higher card on a one-step gap. When neither of you can say anything new, the higher card wins. Deciding this before the session stops it becoming a negotiation, and it errs in the direction pairs habitually get wrong: small teams underestimate more often than they overestimate, because there is nobody spare to absorb the surprise.

Argue against a reference story, never in the abstract. “Is this a 5?” is unanswerable for two people with no third opinion to triangulate against. “Is this bigger than the CSV export we finished in June?” is answerable in one sentence, and it resolves most one-step gaps without either person having to concede anything.

Cap it at two rounds. If the second reveal is still more than one card apart, stop estimating. A persistent split between two people who both know the codebase is not an estimation problem, it is a refinement problem. Split the story, or write a timeboxed spike and size the rest afterwards.

Three is the first size where the format works as written. A majority becomes possible, a single outlying card is a real outlier, and the second round has somewhere to converge to. Most of the adapted rules above stop being necessary.

The failure mode to watch is a 2–1 split that gets settled by counting rather than arguing. It feels like consensus and is not: the single dissenting card is often the person who has actually read the relevant code. The cheapest fix is a standing rule that the minority card explains itself first, before either of the other two says anything.

Counts are voters, not attendees. A product owner who answers questions but never writes the code should be a spectator, which keeps a pair a pair rather than turning it into an awkward three.

Estimating has a fixed cost per story, and in a pair that cost is a noticeable share of the day. Three cases are usually not worth it.

Tickets nobody could get wrong. Copy changes, config flips, a dependency bump. Plenty of pairs stop sizing anything below a threshold and simply count stories, which forecasts about as well once the small items are genuinely uniform.

Work only one of you will touch. If your colleague has never opened the billing service, their card is not a second opinion, it is noise with a number on it. Better: the person doing the work states a size, and the other one challenges it against a finished story of similar shape. You keep the useful scepticism and drop the pretence of independence.

When you only want a forecast. Two people have a stable throughput, and counting completed stories per week predicts about as well as summing points. Estimate when you want the conversation, not when you want the arithmetic.

When you do want the conversation, the mechanics are the same as for any other team. Open a room, share the link and reveal together — it takes about as long as saying a number out loud, and it produces a better one.