Affinity Estimation

What is Affinity Estimation?

We use the term “affinity” to signify that we’re using a technique called “affinity grouping” and applying it in an estimation use case.  Since we’re talking about estimation, we are grouping items based on their relative size, that is, size in relation to each other. And because we’re employing affinity grouping, this approach to estimation tends to be much more rapid than more traditional, story-by-story estimation approaches.

The Concept Behind Affinity Estimation

Let’s say we’re talking about three things, which we’ll call “A,” “B,” and “C,” where:

  • B is the smallest thing in the group
  • C is the largest thing in the group
  • A is somewhere between B and C in size

To put it in a mathematical form,
(C > A)
(A > B)

To sum up, during affinity estimation, we make a quick call on relative size, by starting with a batch of “cards,” (see the Terminology section for more about cards), and then moving them until all cards are arranged based on their relative size, from smallest to biggest, typically with the smallest cards in the left-most column and the largest cards in the right-most column.

What’s the Benefit?

Affinity estimation has been in use in the Agile community for quite a long time, both because:

  • It is a relatively easy technique to master
  • It is possible to rapidly get rough estimates for a significant number of Product Backlog Items (user stories) in a short amount of time


We are most likely to use affinity estimation in situations such as the following:

  • When forming a new team 
  • When starting work on a new product or project
  • Before or during a cross-team Agile planning event such as Release Planning (where multiple teams are involved in planning work, often across multiple iterations or Sprints)

Who Attends?

Most often, the following people are present for affinity estimation:

  • Everybody on the team (all of the Developers, to use Scrum parlance)
  • A Product Manager / Product Owner
  • A facilitator (typically a Scrum Master, if it’s a Scrum team)


Basic inputs include the following:

  • Conceptual understanding of the nature of the product/project, in terms of the business problem to be solved, who benefits from solving it, and desired user/customer outcomes
  • General agreement on the technical stack that the team intends to use
  • A well-formed set of user stories (see Preparing for Success)


The primary output from affinity estimation is:

  • An initial estimate for each user story that the team chose to estimate

Additional outputs that may occur:

  • The creation of one or more user stories that were not in the initial set
  • The combination or removal of one or more user stories
  • Additional clarity on follow-up conversations that may need to occur

Preparing for Success


Be sure to have the following materials available in advance. It’s particularly important to have basic information about each user story to be estimated written out in advance using media/materials as described below.

  • For distributed teams: A tool that makes it easy to create and move virtual cards, such as Mural, Miro, or Trello
  • For collocated teams:
    • A reasonably large tabletop or wall space
    • Index cards (if working on a tabletop) or Post-it Notes (if using a wall)
    • Sharpie fine-point markers (Sharpies are recommended over using pen or pencil, because cards written with Sharpies are easier to read
      from a distance)


The following terminology applies to the attributes of anything that is to be estimated during an affinity estimation session (and also product backlog management in general):

  • Card. A container for a piece of work that needs to be done (thus a “card” can be an Epic, a Feature, or a user story). Because we often use physical cards to represent work items for collocated teams, “card” is a common way to refer to them individually, whether they exist in an electronic tool (such as Azure DevOps, Jira, or GitHub), in physical form, or both. On the card itself, the following fields/attributes are typically visible, in its finished form:
    • Story header (title). The story title should be short enough to easily read at a glance, but still provide enough information that it’s reasonably clear to the reader what the business intent of the thing to be estimated is.
    • Story ID (optional). If the card already exists (in Jira, for instance), feel free to include the card’s unique identifier.
    • Epic/Feature. To help reflect parent/child relationships, it’s a common practice to include the Epic or Feature that the card is associated with.
    • Size. Writing either the T-shirt size, or a number (in story points) is most common.

Note: There are other attributes that are important to include in user stories, which are beyond the scope of this Play. The basic set of attributes as described above is often sufficient for affinity estimation.


The following conventions apply to affinity estimation:

  • Collocated teams: Agree on where on the index card or Post-it note you are going to write each field. For instance, the team might decide to write the ID in the upper left corner of the card, the epic/feature in the upper right corner of the card, the title in the center of the card, and the size in the lower left or lower right corner of the card.
  • Distributed teams: Agree on which fields need to be filled in, and where, in the electronic tool that you’re using, during affinity estimation.


To facilitate an affinity estimation session, the steps look much like this:

  1. Ask the team to pick a card that they think is one of the smallest, and have them move it to the applicable column, e.g., XS or S (if you’re starting with T-shirt sizes).
  2. Ask the team to pick another card that they think is somewhat bigger, and to place it in the applicable column, e.g., M or L.
  3. Have them continue this process for the rest of the cards. 
  4. Once the team is reasonably comfortable with the placement of the cards, and if you started with T-shirt sizes, it is a simple thought exercise to
    convert the T-shirt-sizes to story points, using a convention such as the following:
    • XS = 1 story point
    • S = 3 story points
    • M = 5 story points
    • L = 8 story points
    • XL = 13 story points

At this point, the team is in a better position to have one or more follow-on conversations about the relative size of various items in their backlog.