Sticky-note characters sorting one shared spread of task notes from small to large, with dashed boundary lines grouping the row into buckets and the largest note highlighted.

Affinity estimation: size a big backlog fast

How affinity estimation sizes a whole backlog in one session: the silent-sort steps, when it beats planning poker, and how to turn it into story points.

A new team, a new product, or a backlog that has quietly grown to two hundred items: point each one in planning poker and you are looking at days of meetings. Affinity estimation sizes the same backlog in a single session, often in about an hour. It works because it flips the usual order. The team sorts everything into bigger-and-smaller groups first, with no numbers, and only labels the groups once the relative order is settled. By the time the numbers arrive, the argument they usually cause is already over.

This chapter is a conceptual walkthrough of the technique: what it is, how a session runs, where it earns its place, and where it quietly fails.

What affinity estimation is

Affinity estimation is a relative sizing technique. Instead of asking “how many points is this story?” one item at a time, you ask the whole backlog a simpler question: which of these is bigger than which? The team arranges the items along a line from small to large, grouping ones that feel like similar effort, and the sizes fall out of the arrangement rather than out of a per-item vote.

The mechanism that makes it fast is the one that makes it good: you sort first and put numbers on last. People are slow and quarrelsome at absolute judgments (“is this a 5?”) and quick and fairly reliable at comparative ones (“this is bigger than that”). Affinity estimation leans entirely on the comparison a team is good at and saves the numbers for the very end, when they are almost a formality.

This guide’s estimation techniques chapter compares the main approaches side by side and gives affinity a short entry. This is the long version of that entry. What sets affinity apart from its neighbors there is throughput. It is the technique you reach for when the problem is not “understand this story deeply” but “get a whole pile of stories roughly ordered, today.”

When to use it, and when not to

Take the position plainly: affinity estimation is for breadth and speed, and planning poker is for depth on the near-term work. They are not rivals. They answer different questions.

Reach for affinity estimation when you have a large or unfamiliar backlog and you need a shared baseline fast:

  • A new team sizing its backlog for the first time, with no velocity history to lean on.
  • A new product or epic that has just been broken down into dozens of stories.
  • A refinement session where pointing every item individually would take days you do not have.

Reach for planning poker instead when the stories are few, well understood, and about to be committed. The value of poker is the conversation each story triggers before anyone commits to a sprint. That conversation is worth having on the ten stories at the top of the backlog. It is not worth having, one at a time, on all two hundred.

So the honest framing is this: affinity estimation is a first-pass sizing tool, not a sprint-commitment tool. The near-term work still gets re-estimated with points before the team commits to it. Affinity gets the whole backlog onto the map. Poker plans the next few steps across it.

Affinity small large the whole backlog, one pass Planning poker 5? 3! 3 5 8 a few stories, in depth Breadth first, then depth where you commit.
Affinity estimation covers the whole backlog in one pass. Planning poker goes deep on the few stories that are next.

How to run a session, step by step

Affinity estimation runs on a shared surface everyone can see at once, and it is mostly silent by design.

  1. Put every item on a note. One backlog item per sticky note or card. Do not pre-sort them.
  2. Set a reference. Pick one item the team knows well, place it in the middle of the surface, and agree it is the anchor for “medium.” Everything else gets placed relative to it.
  3. Sort in silence. The team places the remaining items left to right by relative effort, smaller on the left, larger on the right. No discussion yet. Silence is what stops the loudest voice from anchoring the room.
  4. Move a note if you disagree. If you think an item is in the wrong place, move it. No permission needed, no debate.
  5. Discuss only the outliers. A note that keeps getting moved back and forth is the team disagreeing without words. Those, and only those, are worth stopping to talk about. Everything that settled quietly is already agreed.

The discipline is in step three and step five. You are not trying to talk through every item. You are letting the sort surface the handful that actually need a conversation, and leaving the rest alone.

You do not need a specialist estimation tool for this. What you need is one surface the whole team can see and rearrange at the same time: a wall and a stack of sticky notes in a room, or whichever shared canvas your team already works on when people are remote. The constraint is simultaneity, not tooling.

Grouping into buckets and turning it into story points

Once the sort stops moving, you have a smooth left-to-right spread but not yet any numbers. Now, and only now, you draw the lines.

Group the spread into a few clusters and label each one with a value from your usual scale. Some teams use S, M, and L. Most reach for a Fibonacci sequence (1, 2, 3, 5, 8, 13), the same one they would use in poker. The smallest cluster becomes your 1s and 2s, the next your 3s, and so on up the line. Every item in a bucket inherits that bucket’s number.

Committing to numbers last is the whole point, not a detail of sequencing. By the time you assign a 5 to a cluster, the team has already agreed those items belong together and belong to the right of the 3s. There is nothing left to argue about, because the hard question (“is this bigger than that?”) was answered during the sort. The per-story fight (“is it a 3 or a 5?”) that eats planning poker sessions never gets a chance to start.

A backlog sorted into Small, Medium and Large columns on the TeamRetro online whiteboard during an affinity estimation session
Example of affinity estimation in TeamRetro using the online whiteboard.

This is where affinity estimation earns its place twice over: it also surfaces the oversized items early. An item that ends up alone at the far right, well past everything else, is almost always an epic wearing a story’s label. Affinity puts it in plain view during refinement, weeks before it would have ambushed a sprint planning session as an unsplittable 21.

Where affinity estimation falls short

Speed has a price, and it is worth naming before you schedule a session.

It hides disagreement. A silent sort treats quiet as consent. A story that was privately a mix of 3s and 8s can settle into the 5s without anyone noticing, and the disagreement only shows up mid-sprint. Planning poker forces that argument into the open one story at a time, which is exactly why it is slower.

It needs everyone on one surface at the same time. The silent sort depends on people placing and moving items simultaneously. Run it where the team cannot all see and touch the same layout, and the sort collapses into whoever places first, which is the anchoring the method exists to prevent.

It is coarse, and it should stay coarse. The output is a rough band, not a number you defend in sprint planning. Treating an affinity bucket as a committed estimate is how a fast, useful first pass turns into a promise nobody meant to make.

Those three are the reason the technique pairs with poker rather than replacing it: use affinity for the whole backlog, then re-estimate the top of it properly before committing.

A worked example

Say a team has 60 stories for a new reporting module and no history to size against.

They write each story on a card and put one familiar story, “export a report to CSV,” in the middle as the reference. For fifteen minutes the team sorts the rest in silence. A login tweak drifts to the far left, a whole new charting engine slides to the far right, and most items land in a loose cluster around the reference. A few cards get moved twice. Those get a short discussion and a home.

Then they draw four boundary lines and label the clusters 2, 3, 5, and 8. The login tweak and its neighbors are 2s. The charting engine sits alone past the 8s, so the team flags it: it is really an epic, and it gets split before the module is planned. In under an hour, 60 unestimated stories have a shared, defensible size, and the one item that would have derailed a sprint is caught while there is still time to break it up.

Compare that to poker. Sixty stories at three minutes each is three hours of solid discussion, and the team would probably have run out of patience long before the charting engine surfaced.

Where to take it next

Affinity estimation ends with a sized backlog, not a sprint plan. The stories at the top still deserve a closer look before anyone commits to them, and that is planning poker’s job: private votes, a reveal, and a real conversation wherever the numbers disagree. When you get to that step, free planning poker for agile teams is a straightforward way to run it, and the rest of the agile estimation guide covers the story points, velocity, and refinement habits that make the numbers mean something.

Frequently asked questions

What is affinity estimation in agile?

Affinity estimation is a fast, relative sizing technique. The team sorts a backlog into bigger-and-smaller groups first, with no numbers attached, then labels the groups (S, M, and L, or a Fibonacci scale) only once the relative order is settled. Because the numbers come last, the team never gets stuck arguing whether a single item is a 3 or a 5. It is built for sizing a large or brand-new backlog quickly, not for committing to the work of one sprint.

How do you run an affinity estimation session?

Put every backlog item on a note, on a wall or another surface the whole team can see. Pick a reference item, place it in the middle, then have the team silently sort the rest left to right by relative effort, smaller to larger. Anyone who disagrees with a placement moves the note. If a note keeps moving, that is your signal to stop and discuss it. Once the layout stops shifting, draw a few boundary lines to turn the spread into buckets and label them. A session like this can size a couple of hundred items in about an hour.

When should you use affinity estimation instead of planning poker?

Use affinity estimation for first-pass sizing of a large or new backlog, when you need breadth and speed and a shared baseline. Use planning poker for depth on the near-term work a team is about to commit to, where the discussion each story triggers is the point. Affinity gives you a whole backlog roughly sized in one session. Poker gives you a handful of stories understood well enough to pull into a sprint. Most teams use both: affinity to map the terrain, poker to plan the next few steps across it.

How do you turn affinity groups into story points?

Once the items are sorted and grouped, draw boundaries between the clusters and assign each bucket a value from your usual scale, most often a Fibonacci sequence (1, 2, 3, 5, 8, 13). The smallest cluster becomes your 1s or 2s, the next becomes 3s, and so on. Every item in a bucket inherits that bucket’s number. The order matters: you commit to numbers only after the relative sort is settled, which is exactly what keeps the per-item argument from ever starting.

Do you need a tool to run affinity estimation?

Not specifically, but it can help. Having a wall or a stack of sticky notes can work, if you are happy to rewrite it all and retag. The requirement is having a simple space where everyone can see the same layout and move items on it at the same time. So whether you use a stack of sticky notes, or the online whiteboard in TeamRetro, either works.

What are the drawbacks of affinity estimation?

It hides disagreement, because a silent sort treats quiet as consent and a split opinion can settle into a bucket unnoticed. It depends on everyone working on the same surface at the same time, and it degrades into anchoring when they cannot. And it is deliberately coarse, so the output is a rough band rather than an estimate to commit a sprint against. Those limits are why most teams pair it with planning poker for the near-term work instead of using it for everything.

Source: Mike Cohn’s writing on relative estimating at Mountain Goat Software informs the relative-sizing approach described here.