Affinity Estimation: Sizing a Large Backlog Fast
Affinity estimation sizes a large batch of backlog items by silently arranging them along a size spectrum - smallest to largest - by feel, with no per-item discussion until after the sort is done. It's the technique agile teams reach for when Scrum Poker would be too slow for the volume of work in front of them: fifty or a hundred unrefined items that need a rough order, not individually deliberated points. This page covers how it works, when it earns its speed, and where its lack of discussion costs something real.
How it works
Write each item on a card or sticky note (physical or digital). The team - silently, without talking - places each card along a horizontal line: smallest effort on the left, largest on the right, positioned relative to the cards already placed. Nobody explains their reasoning during this phase; the silence is deliberate, the same anchoring concern that drives hidden voting in Scrum Poker applies here too, just resolved through simultaneous silent placement instead of a simultaneous reveal.
Once every item has a position, the team reviews the resulting order together - out loud, this time - and adjusts anything that clearly landed in the wrong place. This review pass is short by design: most of the sort is already correct, and the group discussion is for fixing outliers, not re-litigating the whole spectrum.
Why it's fast
No per-item discussion during the sort. Scrum Poker's value comes from discussion, but discussion has a real time cost - fine for five sprint-ready stories, prohibitive for eighty unrefined backlog items. Affinity estimation trades that discussion for silent, parallel judgment, which scales to a large batch in a fraction of the time.
Placement, not consensus-building. Each person places cards according to their own sense of relative size; the team isn't trying to agree in real time the way a Scrum Poker reveal forces agreement on one number. Disagreement shows up as clustering patterns in the final layout, not as a blocked vote.
A worked example
A team faces 80 unrefined backlog items before a quarterly planning offsite - individually estimating all 80 with Scrum Poker would eat most of a day. Instead: 30 minutes of silent card placement along a spectrum, followed by 15 minutes of the group reviewing the result and nudging the handful of items that clearly landed in the wrong spot (a few items get moved after someone points out "this one actually depends on the migration we haven't scoped yet"). Eighty items sized in 45 minutes - a fraction of the time a full round-by-round approach would take, with most of the accuracy that matters for roadmap-level planning.
What affinity estimation costs you
The speed comes from skipping discussion, and discussion is where Scrum Poker's real value lives - surfacing hidden complexity, dependencies, and disagreement that a silent placement never gets close to. An item can land in the wrong spot on the spectrum simply because nobody happened to know about a hidden dependency, and the quick review pass may not catch it if nobody thinks to raise it. This makes affinity estimation a triage tool, not a substitute for real estimation on the items that are about to enter a sprint - it gets a large backlog into rough order fast, then Scrum Poker takes over for the top slice that's actually being planned.
Turning positions into numbers
A pure affinity sort produces order, not numbers - "this is bigger than that" without a value attached. Teams that need the result to feed a velocity calculation split the spectrum into labeled bands afterward (often mapped onto Fibonacci: everything in this section of the line = 3, this section = 5, and so on). This mapping step is itself a small estimation exercise, and it's where affinity estimation shades into the bucket system - a more structured variant that assigns items to numbered buckets from the start rather than sorting along a continuous line first.
When to use affinity estimation instead of Scrum Poker
| Situation | Better fit |
|---|---|
| 50+ unrefined backlog items need a rough order | Affinity estimation |
| A handful of sprint-ready stories need real discussion | Scrum Poker |
| The team needs a precise, summable points number right now | Scrum Poker (or a mapping step after affinity sorting) |
| Roadmap-level triage before a planning session | Affinity estimation |
Most teams that use affinity estimation don't use it instead of Scrum Poker - they use it first, to get a large backlog into rough shape, then run Scrum Poker on the slice that's actually entering the next sprint. See the full technique comparison for how every technique in the family fits together.
Try it with your own backlog
Affinity estimation itself needs no special tooling - sticky notes on a wall or a digital whiteboard both work. Once the top of your backlog is sorted and refined, create a free room to run real Scrum Poker rounds on the stories that are actually sprint-ready.