Affinity Estimation for Agile Teams
The silent grouping technique that scales agile estimation beyond what planning poker can handle. Size 50, 100, even 200 stories in a single session — without burning the team out.
What Is Affinity Estimation?
Affinity estimation is an agile estimation technique where the team silently groups user stories by relative size on a shared wall (or digital whiteboard) instead of voting on each one with planning poker cards. It is sometimes called affinity mapping estimation, and it was popularized by Lowell Lindstrom as a way to size a quarter's worth of work in the time planning poker would take to size a single sprint.
The mechanic is simple. Lay out columns for XS, S, M, L, XL on a wall. Hand every team member a stack of stories. They silently place each story under the size that feels right. They are allowed to silently move stories that someone else already placed if they disagree. After the silent round, the team discusses only the stories that bounced between sizes — the ones where there was genuine disagreement.
Affinity estimation is not a replacement for planning poker — it is the technique that handles the scale where planning poker breaks down. Planning poker is exquisite for 5 to 15 stories. Affinity estimation is built for 50 to 500. Most mature scrum teams use both, at different times in the backlog lifecycle.
The Affinity Estimation Sizing Buckets
Most teams use the same XS through XL scale as t-shirt sizing, because the goal is rapid bucketing, not precise point values. Some teams add a "???" parking-lot bucket for stories that cannot be sized without more information.
Trivial — copy tweaks, config flips, simple bug fixes that one engineer ships in a few hours.
Well-understood, low-risk work the team has done before. Roughly a day of effort.
Standard story-sized work. Multiple files, some design decisions, but scope is clear. 2–3 days.
Significant work spanning multiple components or developers. About a week.
Large-scale work. Often a candidate for splitting before sprint planning begins.
Too unclear to size. Send back to refinement, write a spike, or rewrite the story.
How to Run an Affinity Estimation Session
1Print or import every story onto cards
Get every backlog item on a physical card or a digital sticky. The medium matters because affinity estimation is a spatial activity — the team needs to physically move stories around. Online whiteboards (Miro, FigJam) work fine for distributed teams.
2Set up the size columns
Lay out columns for XS, S, M, L, XL on the wall or board. Some teams use a horizontal "small to large" gradient instead of discrete buckets. Either works. Add a "???" parking lot for stories that need clarification.
3Silently place every story (round 1)
No talking. Each team member grabs stories at random and places them under the size they think fits. If someone disagrees with a placement they have already seen, they silently move it. Timebox to 15–20 minutes.
4Discuss the contested stories
After the silent round, walk the wall together. The stories that ping-ponged between sizes are where the value lives. Discuss each contested story briefly — one or two minutes — and reach a placement.
5Pull the outliers (round 2)
The product owner or facilitator pulls anything that looks oversized or undersized for a final sanity check. Re-place if needed. Anything still in "???" is sent back to refinement.
6Convert to story points
If your team tracks velocity, map sizes to Fibonacci: XS=1, S=2, M=3 or 5, L=8, XL=13 or 20. Capture the mapping the team agrees on so future sessions stay consistent.
Affinity Estimation vs Planning Poker — Which One When?
Affinity estimation and planning poker solve different problems. Affinity estimation optimizes for throughput — sizing many stories quickly with rough accuracy. Planning poker optimizes for precision — sizing fewer stories with high-quality discussion. Healthy teams use the right tool for the stage of the backlog they are in.
| Situation | Use | Why |
|---|---|---|
| Estimating the next sprint (5–15 stories) | Planning poker | Per-story discussion is exactly what you want when stories are about to be committed. Use ScrumChamps planning poker. |
| Quarterly / PI planning (40+ stories) | Affinity estimation | Planning poker becomes the bottleneck. Affinity estimation lets you size the entire quarter in one session. |
| Brand-new backlog dump | Affinity estimation | Most stories are vague. You need rough buckets, not Fibonacci precision. |
| Mature backlog, refined stories | Planning poker | Stories are ready for the discussion-driven precision planning poker delivers. |
| Mixed scrum + kanban team with continuous flow | Both | Affinity for the long tail, planning poker for the next two weeks of work. |
Mapping Affinity Sizes to Story Points
If your team tracks sprint velocity using Fibonacci story points, you will want to convert your affinity sizes back into numeric values before sprint planning. The exact mapping is a team agreement, not a universal rule, but a common starting point looks like this.
| Affinity Size | Fibonacci Points | Use For |
|---|---|---|
| XS | 1 | Pulls into a sprint without a second thought |
| S | 2–3 | Standard sprint candidate |
| M | 5 | Sprint candidate with some discussion |
| L | 8–13 | Refine before committing |
| XL | 20+ | Split before any sprint planning |
Pro tip: when a story moves from the affinity wall into the next sprint, run a quick planning poker round on it before commitment. Affinity sizing gives you a forecast; planning poker gives you a commitment. Use both.
Common Mistakes to Avoid
Talking during the silent round
The whole point of the silent round is to surface disagreement through movement, not through whoever speaks loudest. If people start chatting, you lose the anti-anchoring benefit that makes affinity estimation work.
Skipping the discussion round
Silent placement alone is not enough. The contested stories — the ones that bounced between sizes — are where the team learns the most. Skipping the discussion turns affinity estimation into a survey rather than an estimation activity.
Using affinity sizes as sprint commitments
Affinity sizes are coarser than planning poker estimates by design. Use them for forecasting and roadmap shaping. Run planning poker on a story before you commit it to a sprint.
Mapping affinity sizes to hours
Same trap as story points. Sizes describe relative effort, not calendar time. Two teams can map M to wildly different durations and both be correct for their context.
Skipping the conversion to Fibonacci
If your sprint metrics are in story points, you have to bridge the two systems. A story marked "M" with no point conversion will get pulled into sprint planning and stall while the team re-estimates from scratch.
Estimate smarter at every backlog level.
Use affinity estimation for the quarterly view, and planning poker for sprint-level commitment.