In a story-point sizing session, why does everyone reveal their number at once?

## The problem the ritual exists to solve Anchoring is a well-documented effect: an arbitrary number offered before a judgement drags that judgement toward it, and people cannot introspect their way out of it. In a sizing discussion the anchor is rarely arbitrary in appearance — it comes from the most senior person, or from whoever speaks first, or from the number written on the item last quarter — but the mechanism is identical. Once it is in the room, everyone else is adjusting from it rather than forming an independent view. This matters because the independent views are the product. The size the team writes down is worth a little; the discovery that two Developers were imagining completely different work is worth a great deal, and it only surfaces if their estimates were formed independently. ## How a round actually runs 1. **Read the item together.** The Product Owner states the intent and answers questions about scope, but stays out of the number. 2. **Everyone commits privately.** Each of the Developers settles on a size without saying it, on a shared ladder of coarse buckets. 3. **Reveal simultaneously.** No one adjusts after seeing another number. 4. **The extremes explain.** The highest and the lowest each say why in a sentence or two — not to defend a position, but to expose the assumption behind it. 5. **Re-vote once.** Almost always the spread collapses, because the disagreement was about information rather than judgement. 6. **Take the larger of the remaining sizes** if a small split survives, and move on. Step 4 is the whole session. The rest is scaffolding that makes step 4 possible. ## Triangulation, not calculation A size is never derived from first principles. It is set by comparison against work the team has already sized and already finished: 'this is bigger than the read-only listing page we called a 3, smaller than the item where we had to learn a new partner format, so it is a 5'. Reference items are what make a scale stable across quarters and across new joiners, and a team that keeps a short, current reference ladder argues far less. Coarse buckets do the complementary work. A widening ladder — 1, 2, 3, 5, 8, 13 — encodes the fact that confidence drops as items get bigger. Two adjacent buckets are a real distinction; there is no honest distinction between neighbouring whole numbers at the large end, and offering one invites a debate that cannot be settled. ## Reading the spread | Spread after reveal | What it usually means | What to do | |---|---|---| | All within one bucket | Shared understanding | Record it and move on | | Two adjacent buckets | Different risk appetite | Take the larger, no discussion needed | | Two buckets apart | One person knows something the others do not | Have both explain, then re-vote | | Far apart, and stable after two re-votes | A genuine unknown inside the item | Stop sizing; raise it as an open question for refinement | The last row is the one teams get wrong most often. A persistent wide split is not a failure of the session — it is the session succeeding. The output is a question for the Product Owner, not a number extracted through fatigue. ## Anti-patterns worth naming - **Averaging the revealed numbers.** The mean of 2 and 13 is not a size; it is a way of not having the conversation that the 2 and the 13 just made necessary. - **Letting the technical lead go first.** This is the anchor the whole practice exists to prevent, restored by habit. - **Voting until the room is unanimous.** Three re-votes over a difference that rounds away in any forecast burns the session and teaches people to vote for peace. - **Sizing to please.** When the Product Owner reacts visibly to large numbers, sizes shrink, and the history that comes out of it forecasts nothing. - **Sizing items nobody has read.** A round on an item the Developers first see in the session produces numbers with no information in them. ## Who votes The Developers size the work, because they are the ones who will do it. The Product Owner is present to clarify intent and scope and to make trade-off decisions when a size reveals the item is more expensive than the value justifies. The Scrum Master facilitates, times the discussion and protects the reveal from being anchored. Neither of them casts a size — anyone who will not build the item does not get a vote in how big it is.