Affinity estimation is a fast way for a team to estimate many product backlog items with story points.
Use affinity estimation when the team has too many items to estimate one at a time with Planning Poker. Instead of discussing every item in depth, the team puts story point values on a wall or table, places product backlog items under those values, and saves detailed discussion for the items that do not settle quickly.
Used well, affinity estimation gives a Product Owner enough information to make prioritization, planning, and tradeoff decisions without turning estimation into a long meeting.
What Affinity Estimation Is
Affinity estimation is a relative estimating technique for quickly assigning story point estimates to a group of product backlog items.
A useful version of affinity estimation starts with the story point values visible before any items are estimated. Put the valid estimate values across the top of a wall, table, or online board. If the team uses a modified Fibonacci sequence, those headings might be:
1, 2, 3, 5, 8, 13, and 20
If the team uses powers of two, the headings might be:
1, 2, 4, 8, 16, 32
Then the team places each product backlog item under the value that seems right.
This is one straightforward way to run affinity estimation, and it is the version this page will use as its starting point. Some teams first sort items by relative size and assign numbers later. That can work, especially when a team is new to story points or does not yet have good baselines.
When a team already has an estimating scale and a few familiar baseline items, putting the numbers on the wall first keeps the session practical. The team estimates directly into the agreed story point values, so the results are immediately useful for prioritization, planning, and tradeoff decisions.
When to Use Affinity Estimation
Use affinity estimation when the team needs rough, useful estimates for many product backlog items.
Planning Poker is excellent when an item deserves discussion. It gives team members time to ask questions, reveal assumptions, and learn from high and low estimates. That discussion is valuable, but it takes time.
Affinity estimation trades some of that discussion for speed. That makes it useful when:
- A Product Owner has a large set of product backlog items and needs approximate estimates
- A team is estimating after a story-writing workshop
- A backlog has grown and needs a first estimating pass
- Stakeholders need a rough sense of cost before choosing among options
- The team wants to identify the largest or most uncertain items quickly
- The estimates only need to be good enough to support a decision
Teams can sometimes estimate more than 100 items in an hour using affinity estimation. More typically, a team might estimate around 60 items in an hour. That can be a significant advantage over Planning Poker, where a reasonable coaching target is often about 20 items per hour.
Those numbers are not promises. They are a way to think about the tradeoff. Affinity estimation is faster. Planning Poker usually creates more shared understanding. A team can use both.
How to Prepare for Affinity Estimation
Set up a shared workspace where product backlog items can be moved easily. For most teams today, that will be an online whiteboard such as Miro, Mural, Lucid Spark, or a similar tool. A physical wall or table with index cards or sticky notes can also work when the team is together in person.
Create one movable card for each product backlog item. The card does not need every detail. A title or short description is usually enough, provided someone can clarify the item if the team has a basic question.
Next, create columns using the team’s valid story point values. These become the headings for the estimates.
Before beginning, remind everyone of the team’s baseline items. Affinity estimation still depends on relative estimating. A 5-point item should be roughly comparable to other items the team has called 5 points in the past.
Who Should Participate
The estimators should be the people who will do the work.
For a cross-functional Scrum team, that means developers in the broad Scrum sense: programmers, testers, designers, database specialists, analysts, technical writers, and others who contribute to delivering the product backlog items.
The Scrum Master or agile coach can facilitate. The Product Owner can attend, especially if the team will need quick clarification on what an item means. But in the basic version of affinity estimation, there is very little talking while cards are being placed. That means the Product Owner does not need to explain every item in detail before it is estimated.
A useful rule is this: include the people needed to estimate, and have someone available to answer basic questions. Do not let the meeting become a detailed backlog refinement session unless that is the intent.
The Basic Affinity Estimation Process
Here is the recommended process.
1. Put Story Point Values on the Wall or Table
Start by placing the team’s valid story point values across the top of the wall, table, or board.
Do this before estimating the first item. The values give everyone a shared set of possible answers. The team is choosing among known story point values, not inventing categories as it goes.
2. Read the First Product Backlog Item
Someone reads the first item to be estimated.
Keep this brief. The goal is to identify the item, not to begin a full discussion. If the team truly does not understand the item, put it aside for clarification rather than letting the affinity session bog down.
3. One Estimator Places the Item Under a Value
Whichever estimator has a good idea of the estimate takes the item and places it under the value they think is best.
If an estimator thinks the item is a 3, that person places it under the 3.
Do this without talking. The silence is important. It keeps the meeting moving and prevents the first person’s explanation from anchoring everyone else.
4. Others Can Move the Item Once
Everyone else considers the placement.
If someone disagrees, they move the item to the value they think is better. For example, if one estimator places an item under 3 and another thinks it should be a 5, the second estimator moves the item from 3 to 5.
Again, do this without talking.
Then the team pauses briefly. If no one moves the item again, the item is estimated at its new value.
5. Move the Item to a Discussion Pile If It Would Move Again
If someone disagrees with a move from 3 to 5 and wants to move the item again, the item does not move back. Instead, it comes out of play and goes into a pile of items that need discussion.
The same rule applies if someone else wants to move it to a different number.
An item can be placed once and moved once. If anyone wants to move it a second time, set it aside.
This is the rule that keeps affinity estimation fast. The team is not trying to force agreement on every item during the first pass. It is quickly estimating the items that are easy enough to estimate and identifying the items that deserve a better conversation.
6. Continue Through the Items
Read the next item. Someone places it under a value. Someone else may move it once. If a second move is needed, put it in the discussion pile.
Keep going until the team has worked through the items selected for the session.
7. Use Planning Poker for the Discussion Pile
After the fast pass, return to the items that were pulled out for discussion.
Planning Poker works well for those items. Affinity estimation is great for speed, but its weakness is the limited conversation. Planning Poker gives the team a chance to explore the hidden parts of the work, especially when people see the item differently.
In many cases, this combination works well: use affinity estimation for the items that settle quickly, then use Planning Poker for the items that need real discussion.
Why the No-Talking Rule Helps
The no-talking rule can feel strange at first. Teams are used to estimating by talking.
In affinity estimation, silence is what creates speed. It also reduces the chance that one confident person will shape the estimate before others have formed their own view.
The team still communicates. It communicates by placing and moving cards.
A card that stays where it was placed tells the team there is enough agreement. A card that moves once tells the team someone saw it differently, but the new placement is acceptable. A card that would move again tells the team the item needs discussion.
That last signal is useful. The team has discovered an item where assumptions differ, risk is unclear, or the item may not be understood well enough to estimate quickly.
What to Do with Items That Need Discussion
Do not treat the discussion pile as a failure.
Those items are the ones affinity estimation helped you find. Something about them deserves more attention.
Common reasons include:
- The item is too vague
- The item hides significant technical work
- The team members are making different assumptions
- The Product Owner’s intent is unclear
- The item is too large and should be split
- The work includes risk or uncertainty the team needs to explore
For those items, use Planning Poker, product backlog refinement, or a short research spike. The right next step depends on why the item was set aside.
Sometimes the team can estimate the item later in the same meeting. Often I prefer estimating those items later, after someone has had time to answer the question or investigate the uncertainty.
Variations on Affinity Estimation
The basic process works well, but teams can adapt it.
Shuffle the Items First
One variation is to shuffle the product backlog items before estimating.
This randomizes the sequence. Without shuffling, related items may appear together because they were printed from the backlog in order. Some teams believe randomizing helps create more consistent estimates.
There may not be much practical difference. There may even be a small speed advantage to estimating similar items together. But shuffling is easy to try.
Allow Brief Timed Discussion
Another variation is to allow talking while cards are being placed and moved.
If you do this, use a timer. One or two minutes is usually enough. Without a timer, the session can slowly become Planning Poker without the cards.
A related variation is to allow 30 seconds or a minute of discussion before the first placement of each item. Keep this short. The more discussion you allow before placement, the more you reduce the speed advantage of affinity estimation.
Rotate the Initial Placement
In the basic approach, anyone who thinks they know the estimate can place the item first.
On some teams, this leads to everyone staring at everyone else. When that happens, rotate the initial placement. One person places the first item, the next person places the next item, and so on.
The rotation is not meant to give ownership of the estimate to one person. The rest of the team can still move the item once.
Sort First, Then Assign Numbers
Another variation starts without numbers.
The first item is placed in the middle. The next item is placed to the left if it is smaller or to the right if it is larger. Items of similar size are stacked vertically. After all items are sorted, the team assigns story point values to the groupings.
This can be useful when a team is new to story points or has not yet established a good baseline. But when a team already has a valid estimating sequence and baseline, start by putting the numbers on the wall and placing items under those numbers.
Use T-Shirt Sizes Temporarily
A team can place items under headings such as small, medium, large, and extra large. After sorting, the team maps those categories to story point values.
This can be a gentle way to start with a team that is uncomfortable with numbers. But if the team’s goal is story point estimates, eventually the categories need to map to story points.
Discuss Second-Move Items Immediately
Some teams want to discuss an item as soon as someone wants to move it a second time.
That can work, but it often interrupts the flow. A better default is to let the team move quickly through the items that can be estimated quickly, then discuss the difficult items together at the end.
When Affinity Estimation Works Well
Affinity estimation works best when the team already has some shared understanding of story points and a baseline for comparison.
It also works best when the estimates are needed for decisions that can tolerate approximate answers. For example, a Product Owner may need to know whether a feature area is likely small, medium, or large compared with other options. A team may need to identify which items are clearly too large. A manager may need a rough sense of scope before a larger planning conversation.
In those situations, affinity estimation can provide enough information quickly.
If the decision requires careful understanding of a small number of high-priority items, use a more discussion-heavy technique.
Common Affinity Estimation Problems
Talking Too Much
Affinity estimation loses its advantage when every item turns into a conversation. Use the card movement rules to separate easy items from items that need discussion.
Letting One Person Dominate
If the same person places most of the cards and others rarely move them, the team may not be estimating as a team. Rotate the first placement or encourage others to move cards when they disagree.
Ignoring the Discussion Pile
The items set aside for discussion still need to be estimated, refined, split, or researched. Do not leave them in a pile indefinitely.
Using Affinity Estimation Without a Baseline
A team can sort items from smaller to larger without a baseline, but assigning story points works better when the team has a few known items to compare against.
Treating Fast Estimates as Perfect Estimates
Affinity estimates are rough. That is usually acceptable when they are used for the right decisions. As an item moves closer to implementation, the team may need more discussion.
A Short Affinity Estimation Example
Imagine a Product Owner brings 60 product backlog items to a team. Some are likely to be small wording changes. Others are new workflows, integrations, reporting requests, and uncertain technical work.
Estimating each item with Planning Poker could take hours. Instead, the team places story point values across a wall: 1, 2, 3, 5, 8, 13, 20, and 40.
The team starts by placing a few familiar items under values it already understands. Those become temporary baselines. Then the team silently places the remaining items. If someone disagrees with placement, they move the item once. If someone else would move it again, the item goes into a discussion pile.
At the end, most items have rough estimates. The discussion pile contains the items where conversation will be most valuable.
That is the point. Affinity estimation is not a way to avoid thinking. It is a way to spend thinking time where it matters most.
Affinity Estimation Versus Planning Poker
Affinity estimation and Planning Poker solve different problems.
Planning Poker is better when the team needs careful discussion on a smaller number of product backlog items. It gives everyone a voice and makes disagreement visible.
Affinity estimation is better when the team needs rough estimates for many items. It helps the Product Owner see the relative size of a backlog, identify large or uncertain items, and make broad ordering or planning decisions.
Many teams use both. They start with affinity estimation to sort a large group of items, then use Planning Poker on items that are near-term, controversial, surprisingly large, or important for a planning decision.
Using the Results After the Session
The output of affinity estimation is a set of rough estimates and a list of items that need more attention.
Do not treat every number as equally reliable. An item that settled quickly under a five may be good enough for broad planning. An item that moved several times before landing at eight probably needs a note explaining the assumption behind the estimate. An item in the discussion pile may need refinement, splitting, or a Product Owner decision before its estimate is useful.
After the session, the Product Owner and team should decide what to do with each type of item:
- Items that settled quickly can usually keep their estimates.
- Large items may need story splitting.
- Confusing items may need more detail or examples.
- Risky items may need a spike or technical conversation.
- Low-value items may be removed instead of refined further.
Affinity estimation is most useful when the team acts on what it learns.
Remote Affinity Estimation
Remote teams can use affinity estimation with an online whiteboard or backlog tool.
The mechanics change, but the principles remain the same. Make the scale visible. Give each estimator a way to move items. Limit talking during the first pass. Mark items that move more than once. Then discuss only the items that need discussion.
Remote teams should be especially careful about silence. Silence may mean agreement, confusion, distraction, or reluctance to challenge someone. A facilitator can help by asking, "Which items surprised you?" or "Which item would you most want to move if we had one more pass?"
Common Questions
Is Affinity Estimation Less Accurate Than Planning Poker?
Often, yes. Planning Poker usually creates more discussion, and that discussion can improve estimates. Affinity estimation is faster. Use it when speed and approximate estimates are more valuable than detailed conversation on every item.
Should the Product Owner Be in the Meeting?
The Product Owner should be available to answer questions. In the basic no-talking version, the Product Owner may not need to participate in every placement. If the team needs frequent clarification, that may be a sign the items need refinement before they can be estimated well.
Can Affinity Estimation Use Story Points?
Yes. The recommended version starts by putting story point values on the wall or table and placing items under those values.
What Should We Do When a Card Keeps Moving?
Take it out of play and put it in a discussion pile. Estimate it later with Planning Poker or refine it before estimating.
Can We Use Affinity Estimation Remotely?
Yes. Use an online whiteboard or backlog tool that allows cards to be moved into columns. Keep the same rules: values first, silent placement, one move allowed, second move sends the item to discussion.
How Many Items Can We Estimate This Way?
It depends on the team and the items, but affinity estimation is meant for estimating many items quickly. If the team only has a few high-priority items, Planning Poker may be a better choice.
Recommended Articles
- Four Reasons Agile Teams Estimate Product Backlog Items
- 7 Ways to Get the Best Estimates of Story Size
- Better Estimates Are Possible on Agile Teams
- Why the Fibonacci Sequence Works Well for Estimating
- Don't Average During Planning Poker
Related Pages
- Product Backlog Refinement helps teams create enough shared understanding for useful estimates.
- User Stories helps teams write product backlog items that are easier to compare and estimate.