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...
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?
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:
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 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:
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.
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.
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.
You may expect to get all or any of the following out of affinity estimation:
Three major characteristics of affinity estimation are as under:
If you are going to do an affinity estimation exercise, here are a few useful tips for you:
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.