Skip to content
Mountain Goat Software
  • Ways We Help

    • Agile CoachingGet expert guidance tailored to your teams, leaders, and real-world challenges.
    • Backlog Story ImprovementStrengthen backlog items so teams can plan clearly and deliver valuable work.
    • Estimating & PlanningBuild realistic estimates and plans that support confident delivery decisions.
    • Leadership AlignmentAlign leaders around priorities, expectations, and the conditions agile teams need.
    • Team Improvement SprintsTurn focused learning into lasting changes through guided practice over time.
    • Scrum Team ImprovementHelp Scrum teams improve collaboration, execution, and results on real work.

    Who We Help

    Helping Scrum teams and product, engineering, and organizational leaders improve how they work.

    Explore Who We Help →

    Workshops

    • View All Workshops
    • Working on a Scrum Team
    • Backlog Refinement Workshop
    • Mastering User Stories
    • Story-Writing Workshop
    • Accurate Agile Planning
    • Effective Scrum Master
    • Agile for Leaders
    • Effective Product Owner
    • Team Reset
    • Agile Coaching
    • Introduction to Agile
    • Certified ScrumMaster
    • Certified Scrum Product Owner

    Explore Services

    • View All Services
    • Compare Workshops
    • ROI Calculator
    • Results OverviewSee how private, team-based agile support improves backlogs, planning, Scrum events, and leadership visibility.
    • What Changes in 90 DaysSee the practical improvements teams and leaders can achieve after working with us.
    • Client StoriesRead how organizations have applied what they learned and improved how they work.
    • TestimonialsHear directly from participants, leaders, and longtime clients.
  • Agile Guides

    • New to Agile or Scrum
    • Scrum
    • User Stories
    • Product Backlog
    • Story Points
    • Agile Planning and Forecasting
    • Product Ownership
    • Agile Teams and Collaboration
    • Agile Leadership
    • Leading Agile Initiatives

    More Resources

    • The Mountain Goat Software Blog
    • Videos
    • Webinars
    • Free Tools
    • Books by Mike Cohn
    • Presentations

    Stay Connected

    • Weekly Tips from Mike Cohn
    • Mountain Goat Software on YouTube
    • Connect with Mike on LinkedIn

    Featured Resources

    • Agile Video LibraryBrowse Video Playlists from Mike on Scrum, user stories, planning, and leadership.
    • Scrum Reset DiagnosticFind the one problem to fix first and run a practical two-sprint reset.
  • About Mountain Goat Software

    • Our CompanyLearn who we are and how Mountain Goat Software helps teams and organizations.
    • Mike CohnMeet our founder, author, and longtime agile practitioner.

    Get In Touch

    • Book a Call
    • Send an Email
  • Search
  • Book a Call
Book a Call
  1. Home
  2. Agile
  3. Story Points
  4. Affinity Estimation

Affinity Estimation

In This Topic

  • What Affinity Estimation Is
  • When to Use Affinity Estimation
  • How to Prepare for Affinity Estimation
  • Who Should Participate
  • The Basic Affinity Estimation Process
  • Why the No-Talking Rule Helps
  • What to Do with Items That Need Discussion
  • Variations on Affinity Estimation
  • When Affinity Estimation Works Well
  • Common Affinity Estimation Problems
  • A Short Affinity Estimation Example
  • Affinity Estimation Versus Planning Poker
  • Using the Results After the Session
  • Remote Affinity Estimation
  • FAQ
  • Explore Further

Guides ▾

  • New to Agile or Scrum
  • Scrum
  • Agile Teams and Collaboration
  • Product Ownership
  • Product Backlog
  • User Stories
  • Story Points
    • Planning Poker
    • Affinity Estimation
    • Story Point Scales
    • Story Point Baselines
    • Getting Better Story Point Estimates
    • Introducing Story Points to a Team
    • Common Story Point Problems
  • Agile Planning and Forecasting
  • Agile Leadership
  • Leading Agile Initiatives
Close

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. For more detail, see 7 Ways to Get the Best Estimates of Story Size.

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?"

FAQ

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.

Last updated August 2nd, 2026

Scrum Cheat Sheet

Get Your Free Scrum Cheat Sheet

Keep Scrum's roles, events, artifacts, and core rules close at hand with a free quick-reference cheat sheet.

Download Now

Explore Further

Article artwork for 7 Ways to Get the Best Estimates of Story Size.
Article

7 Ways to Get the Best Estimates of Story Size

Featured

Agile teams often struggle to estimate product backlog items. Here are 7 ways to make solid improvements.

Article artwork for Four Reasons Agile Teams Estimate Product Backlog Items.
Article

Four Reasons Agile Teams Estimate Product Backlog Items

Featured

Estimating product backlog items provides benefits beyond predicting when a project will be finished.

A folding ruler sits inside a circle, upon which rotate planning poker cards, gears, and a clock. Text to the right of the image reads, Story Points are an Estimate of Effort, as Influenced by the amount of work, complexity, risk and uncertainty.
Article

What Are Agile Story Points?

Featured

Understand what story points measure and why they are often misunderstood.

Article artwork for Why the Fibonacci Sequence Works Well for Estimating.
Article

Why the Fibonacci Sequence Works Well for Estimating

If you’ve estimated with Planning Poker, you may very well have used cards with either the FIbonacci sequence, or a modified Fibonacci sequence.

Article artwork for Why the Whole Team Should Participate When Estimating.
Article

Why the Whole Team Should Participate When Estimating

Even though not everyone may work on a product backlog item, it’s still worth having the full team estimate. Here’s why.

An agile coach and team discussing their work together.
Coaching

Estimating & Planning

Improve estimates, forecasts, release planning, and conversations about scope, timing, and risk.

Estimating

Build practical agile estimating skills with story points, planning poker, triangulation, velocity, and techniques for making useful forecasts without chasing false precision.

Article artwork for The Best Way to Establish a Baseline When Playing Planning Poker.
Article

The Best Way to Establish a Baseline When Playing Planning Poker

Establish useful baselines so Planning Poker estimates stay relative.

Text graphic: Keep backlog detail just enough and just in time.
Article

Writing the Product Backlog Just in Time and Just Enough

Keep backlog detail just enough and just in time.

Article artwork for The Surprising Cost of Bad Estimates.
Article

The Surprising Cost of Bad Estimates

See how bad estimates create costs beyond missed dates.

AI Prompts for user personas, story writing, acceptance criteria and more
Article

How to Use AI for Product Discovery and Writing Better User Stories

Use AI to support product discovery, user interviews, and writing better user stories.

Article artwork for How the Story Critic AI Skill Helps Teams Write Better Backlog Items.
Article

How the Story Critic AI Skill Helps Teams Write Better Backlog Items

See how AI coaching can help teams write clearer, smaller, more testable backlog items.

Text graphic: Re-estimate only when the new estimate helps.
Article

To Re-estimate or not; that is the question

When we estimate it is important that we not mix knowledge-before-the-fact with knowledge-after-the-fact.

Article artwork for Nine Questions Scrum Masters and Product Owners Should Be Asking.
Article

Nine Questions Scrum Masters and Product Owners Should Be Asking

Use better questions to improve collaboration, decision-making, and team ownership.

Triangulate for better agile estimates. A new estimate is put forward for consideration. To decide if The Estimate Is Right, the team can compare the new estimate against an existing smaller estimate and and existing larger estimate.
Article

Automatically Triangulating Estimates in Planning Poker

Compare new estimates with known stories to keep Planning Poker results consistent.

Article artwork for Estimating and Planning in Agile: Why They Still Matter in 2026.
Article

Estimating and Planning in Agile: Why They Still Matter in 2026

By 2026, most agile practitioners have plenty of scar tissue when it comes to estimating and planning.

Article artwork for Getting Better Estimates Is Easier Than You Think.
Article

Getting Better Estimates Is Easier Than You Think

Is your team hesitant to estimate? Here's the secret: we're not as bad (or as good!

Text graphic: Estimate product backlog items before sprint planning.
Article

2 Times to Play Planning Poker and 1 Time Not To

I recommend using Planning Poker on product backlog items rather than on the tasks that make up a sprint backlog.

Scrum meetings are an investment in Scrum success. Orgs who are new to Scrum often feel as if Scrum teams meet too much. When they dig deeper, they discover the meeting time is about the same, but the meetings are more visible because they have names.
Article

Does Scrum Have Too Many Meetings?

Are teams complaining about Scrum meetings? Learn why that happens, and how to fix it.

Becoming a product owner is a big decision. Have you considered becoming a product owner? Maybe you should.
Article

Should You Become a Product Owner?

Explore the skills, paths, and tradeoffs to consider before stepping into the product owner role.

Planning documents, charts, and estimation notes.
Workshop

Accurate Agile Planning

Help teams create credible forecasts, plan under uncertainty, and make better decisions about scope, timing, risk, and tradeoffs.

Plan Visualizer
Tool

Plan Visualizer

The Plan Visualizer is a free agile forecasting tool for testing whether a target scope can be completed by a target deadline. It plots the plan against a low and high velocity estimate so teams and stakeholders can…

Illustration representing the Velocity Range Calculator.
Tool

Velocity Range Calculator

Use this to calculate a velocity range from historical sprint data and support milestone forecasting.

Training

  • Services
  • Agile Coaching
  • Backlog Story Improvement
  • Estimating & Planning
  • Leadership Alignment
  • Agile Training ROI Calculator
  • Team Improvement Sprints
  • Scrum Team Improvement
  • Private Workshops
  • View All Workshops
  • Compare Workshops

Agile Guides

  • Topic Hubs
  • New to Agile or Scrum
  • Scrum
  • Agile Teams and Collaboration
  • Product Ownership
  • Product Backlog
  • User Stories
  • Story Points
  • Agile Planning and Forecasting
  • Agile Leadership
  • Leading Agile Initiatives

Resources

  • Agile and Scrum Videos
  • Webinars
  • The Mountain Goat Software Blog
  • Books by Mike Cohn
  • Free Tools
  • Weekly Tips from Mike Cohn

About Us

  • About MGS
  • Our Company
  • Mike Cohn
  • Client Stories
  • Testimonials
  • Contact Us
  • Book a Call
  • Send an Email
Mountain Goat Software
Copyright ©1998–2026 Mountain Goat Software. All Rights Reserved.
  • Contact Us
  • Terms and Conditions
  • Privacy Policy