Affinity Estimation

Affinity Estimation is a technique many agile teams use too quickly and easily estimate a large number of user stories in story points. Other estimation methods like Planning Poker or Bucket System are effective methods of establishing consensus in small projects. Affinity Estimation is a great technique if a project has just started, and have a backlog that hasn’t been estimated yet, or in preparation for release planning. It is useful when the team is small and the number of participants is less as well.

Affinity Estimation is an Agile estimation technique that focuses on categorizing user stories or tasks into groups based on their relative complexity. Rather than assigning specific numeric values, teams use the concept of affinity to create clusters or groups of similar-sized items.

Key Characteristics:

  1. Collaborative Nature: Affinity Estimation involves the entire Agile team, promoting collaboration and shared understanding of the project’s scope.
  2. Quick and Iterative: The process is designed to be fast and iterative, enabling teams to make rapid estimations without dwelling on precise numeric values.
  1. Speed and Efficiency:
    • Affinity Estimation is a quick and efficient process, saving time compared to more detailed estimation techniques.
  2. Team Collaboration:
    • It encourages collaboration and ensures that the entire Agile team contributes to the estimation process.
  3. Adaptability:
    • The method is adaptable, allowing teams to refine estimates as they gain a better understanding of the project.
  4. Reduces Overthinking:
    • By focusing on relative sizing and grouping, teams can avoid overanalyzing and get a quick sense of the overall effort.

Affinity Estimation Steps

Three steps of Affinity Estimation are

  • Silent Relative Sizing
  • Editing the Wall
  • Placing items in correct bucket

Step 1: Silent Relative Sizing

  • First a horizontal scale is chosen. One end of the scale is marked with “Smaller” and the other end is marked with “Larger”
  • The product owner provides the user stories to the team. 
  • Each participant estimates their story solely without any discussion with other participants and after estimation, places it at the correct location on the scale, anywhere between “Smaller” and “Larger”.
  • Team members will be asked to come up to the wall with a subset of the Product Backlog items provided by the Product Owner
  • Team members will be expected to size each item relative to other items on the wall considering the effort involved in implementing it based on our Definition of Done
  • This is a silent part of the exercise so please refrain from speaking to others except for basic comments like “move out of my way”
  • The Product Owner and any helpful stakeholders/supporters will be present towards the back of this room to provide clarity when needed, so please ask them for help when not sure about an item
  • Team members may use a place in the room to capture questionable Product Backlog items such as items which are too ambiguous to size even after discussion with the Product Owner
  • Think of the wall as a spectrum of size from Smaller to Larger; items stacked vertically on the wall are about the same relative size in effort

Step 2: Editing the Wall

  • Once each story is placed on the scale team members edit the relative sizes on the wall. For this team discussed about the story with each other about its design, implementation or any challenges. Team gets all the doubts clarified from Product Owner as well.
  • Based on the understanding made during discussion, team re-arranges its story on the scale if required.

Step 3: Placing items in correct bucket

  • The scale “Smaller” to “Larger” is divided and marked appropriately with the markers of XS, S, M, L, and XL if we use t-shirt sizing technique or with 0, 1, 2, 3, 5, 8, 13, and so on, if we use Fibonacci series of planning poker estimating technique.
  • Team member now places their stories, which were on scale “Smaller” to “Larger”, to appropriate bucket of the converted scale.

Sample mapping to convert Smaller to Larger to story point 

  • XS – 1
  • S   – 2
  • M  – 3
  • L  –  5
  • XL – 8
  • If the product owner sees a requirement on the medium table that they thought would be a small, don’t waste any time discussing it. The development team ultimately gets to say the size of the requirement, and a one-size difference is not worth the time to discuss.
  • If you have greater than one table of difference between where development team members think a card should be placed and where the product owner thought it would be placed, put that card on the Clarify table. The development team may not have understood the product owner’s explanation of the requirement.
  • The Affinity Estimating exercise is best conducted on Product Backlogs larger than 20 items. It is best when you have at least 40 items which allows for groupings to easily become apparent.
  • Some Product Backlog items may not be understood enough to estimate at all. Place these on a space separate from the estimating wall so the Product Owner can take them away and clarify them.
  • Leaving the sizing nomenclature off the wall until the full sizing steps 1 & 2 are completed helps Team(s) use relative sizing.
  • Ask the Team(s) to decide on a common sizing nomenclature such as T-shirt (XS, S, M, L, XL), Fibonacci (1, 2, 3, 5, 8, 13), or 2n (2, 4, 8, 16, 32) before starting step 3 if they haven’t already decided.
  • Spacing of sizes relative to the gap between the numbers across the wall can help team members put items into size buckets.
  • Be careful and work with the Product Owner and their supporters to understand how the “challenge” of sizes can be effective and still respect the Team(s) estimates.
  • ScrumMaster must be ready to do heavy facilitation with a single team. If you are conducting the exercise with multiple teams it is imperative that each step is setup well. I have facilitated this exercise with 3, 4, and 5 product teams in the room. It works well in this situation with healthy facilitation.
  • This exercise does not remove the need to conduct more in depth estimating sessions such as with Planning Poker as the Product Backlog evolves.

Summary

Affinity Estimation is a valuable tool in the Agile toolkit, providing teams with a streamlined and collaborative approach to project sizing. By emphasizing relative complexity and quick iterations, teams can make informed decisions without getting bogged down in detailed numerical estimations. Adopting Affinity Estimation contributes to the Agile principles of flexibility, collaboration, and delivering value in a timely manner.

Characteristics of agile affinity estimation are Quick and Easy, Making decisions fairly transparent and visible & Creating a positive and collaborative experience.

  1. Planning Poker – Agile Estimation Method
  2. Bucket System – Agile Estimation Method
  3. Affinity Estimation – Agile Estimation Method
  4. Dot Voting – Agile Estimation Method
  5. White Elephant Sizing – Agile Estimation Method
Scroll to Top