Affinity Estimation: What It Means in Agile and Why

Welcome to PremierAgile!

Recognized for 'Outstanding Leadership in Education and Learning' by the Education 2.0 Conference Dubai 2024

We are proudly recognized for Excellence in Agile Consulting and Transformation Services – 2023 by Economic Times and Times of India!

*Avail a Flat 10% Discount Across all our certification courses

*Avail Zero Interest EMI

We Offer World-class guidance to transform yourself as well as your organizations

Mega Offer! Access our Advanced courses for  just 21,999/- +Taxes

PremierAgile

With an objective to enable continuous learning and progression for our learners, PremierAgile curated several learning articles in the areas of Agile, Scrum, Product Ownership, Scaling, Agile Leadership, Tools & Frameworks, latest market trends, new innovations etc...

What Is Affinity Estimation In Agile?

Changes in software development are taking place all the time meant to bring improvements in it. There is rapid growth in this field and full-stack web frameworks are making the development faster and encouraging agility. But there is still one area of software development that has remained a problem point and that is Estimation. A lot of work still needs to be done on this aspect.

Well, the fact is that estimation has become an integral part of the whole software development business now where clients themselves ask for it. When you are bound to provide estimates to your clients, it is better to do it as best as you can. If you are practicing Agile methodology, the time for giving estimates in days or hours is gone. And story point estimation also can become problematic. So what is the better, simpler, and quicker solution? Well, Affinity Estimation is the answer to improving software estimation. But what is affinity estimation?

What Is Affinity Estimation?

The affinity estimation technique is used by many of those Agile teams who want to estimate a large number of user stories in story points in a faster and easier way. But it can help in improving the planning and estimation parts of these techniques. In affinity estimation, story points are assigned to user stories. The term affinity here implies that a technique of affinity grouping is being used and is being applied in an estimation use case. And for estimation, we create groups of items on the basis of their sizes in relation to each other.

For small projects, estimation techniques like bucket system and planning poker can be used effectively for arriving at a consensus. However, affinity estimation is more useful for projects that have just started and there is a backlog that has not been estimated or when preparation for release planning is to be done. There are three steps of affinity estimation. These are:

  1. Silent Relative Sizing
  2. Editing the Wall
  3. Placing Items In the Right Bucket

 Let's discuss these steps in detail. But before beginning the affinity estimation, the Product Owner has to make sure that he has a list of items in the Product Backlog that which team or teams have to size and should prioritize the backlog. 

Silent Relative Sizing

Silent Relative Sizing is done on a horizontal scale or an extra-Large post-it note or index card without team members speaking with each other. The two extreme sides of the scale are marked “smaller” and “larger”. Similarly, when a post-it note or an index card is used, one note is placed on each end with “smaller” and “larger” written on them.

It is followed by the team members being provided with user stories by the Product Owner.

Without any discussion or consultation with other participants, every participant estimates their story individually and once the estimation is completed, places it in the increasing order on the wall or scale between the two ends depending on the individual participant's estimation. 

 It is better to keep the following things in mind while undertaking the Silent Relative Sizing exercise:

  • Every team member will be provided a subset of backlog items by the Product Owner and will be asked to come up to the wall with that subset
  • Every team member should size each item in relation to other items on the wall taking into consideration the effort required to implement it.
  • As we have already mentioned, members do not consult or discuss with each other, they are not expected to speak with each other during this exercise.
  • The Product Owner or other stakeholders may prove to be helpful in case some clarity is required on a certain item. The team members may consult them.
  • The team may select and designate a place in the room where those items can be placed for whom consensus could not be arrived at.
  • Imagine that the wall is a vertical stack of 'smaller' to 'larger' sizes and the stacked items are almost of the same size as far as effort is concerned.

The Silent Relative Sizing exercise is carried out till the time all the Product Backlog items are either on the wall or in the space earmarked for questionable items. 

Editing The Wall

Now the next step is that the relative sizing put on the wall has to be edited by the teams. Team members then read these items on the wall and move them around towards the 'smaller' direction or 'larger’ direction, as appropriate. Here, the team should be explained by the Product Owner that they have to be mindful of the estimations of other team members and should involve them in discussions if necessary before making any extreme moves. So, the team members have a discussion about the story with each other regarding its design and implementation and challenges, if there are any.

Some discussions or thoughts about the missing backlog items can be seen taking place and the Product Owner is being asked to provide more and more clarifications. This may go on till the time teams start stabilizing their estimations and there are not many changes taking place on the scale. And on the basis of the understanding arrived at during the discussions, the team re-arranges its story on the wall if it feels the need to do so.

Placing Items Into The Right Bucket

After all, the Product Backlog items are placed on the wall and each one of them is edited by the team, now is the time to place each of them in the right size bucket. On the basis of what nomenclature the team has decided to use, place the size between smaller and larger on the spectrum on the top of the wall. Like, if the team has decided to use the Fibonacci series, the scale is marked 0, 1, 2, 3, 5, 8, 13, and so on. And if it has been decided to use T-Shirt sizing, then the scale is marked with XS, S, M, L, and XL. So now the team members place the stories from 'smaller' to 'larger' in the appropriate bucket.

If there are any major disagreements, the Product Owner is asked to review them. The Product Owner reviews these disagreements. If the Product Owner thinks that an item placed on the medium table should be on the small table, no time is wasted on any discussion. It is the Developers that have the ultimate say in the size of the requirement and for a difference of one size, there is no point in wasting time in discussion. But if the difference between them is more than one table, then the item is placed on the clarified table. Chances are that the Developers have not understood the explanation of the Product Owner regarding the requirement.

Output From Affinity Estimation 

You may expect to get all or any of the following out of affinity estimation:

  • An initial estimation of all the user stories that the team has chosen to estimate
  • One or more additional user stories may be created that were not in the initial list
  • One or more user stories may be combined or removed
  • If any follow-up conversations are required, there is extra clarity on that

Three major characteristics of affinity estimation are as under:

  • It is faster and easy to work
  • It makes the decisions quite transparent and visible to all concerned
  • It creates an atmosphere of positivity and cooperation

If you are going to do an affinity estimation exercise, here are a few useful tips for you:

  • The best results from the affinity estimation exercise are obtained when the Product Backlog items are more than 20. It is better if there are a minimum of 40 items so that groupings can become easily apparent.
  • There may not be enough clarity about some Product Backlog items and you may not be able to estimate them at all. You can put them in a place chosen for this purpose and which is not near to the estimating wall so that the Product Owner can come, look at them, and issue whatever clarifications are needed.
  • It will be better to keep the sizing denotation off the sizing wall until the first two sizing steps are completed. This will help the team in using relative sizing.
  • If the team has not decided on the sizing nomenclature e.g. Fibonacci or T-Shirt sizing, ask them to decide before step three of estimation is started (placing in the right bucket).
  • The gap on the wall between the sizes and the numbers in relation to each other will help the members of the team in putting items into the size buckets.
  • It is important to work with the Product Owner so that you get a good understanding of the effectiveness of sizes and at the same time the estimates of the team can also be given respect.
  • Scrum Master has to be prepared to provide heavy assistance to a single team. And if the exercise is being conducted with more than one team, it is necessary to set up each step well. 

So, in the end, we can say that affinity estimation is a good technique for speeding up the process. If you have huge Backlogs, or your project is in the initial stages only, affinity estimation will be a very useful technique for finding the preliminary estimates. 

References
  1. https://digital.ai/catalyst-blog/why-affinity-estimation
  2. https://Scrumology.com/guest-post-affinity-estimating-a-how-to
  3. https://www.techagilist.com/Agile/Scrum/affinity-estimation-Agile-estimation-method


Author

Paula

Is a passionate learner and blogger on Agile, Scrum and Scaling areas. She has been following and practicing these areas for several years and now converting those experiences into useful articles for your continuous learning.