Estimation is an integral part of any project work. The end goal of estimation is to know the efforts required to complete a certain set of work. When done rightly, estimation helps in determining the timeframe, feasibility, and similar other insights. Moreover, estimation also encourages discussion that results in better understanding and collaboration.
For decades, estimation has been done in an absolute manner, i.e., estimate the efforts/time it will take to complete the task without comparison with other relevant datasets. No matter what industry we consider, absolute estimation finds its existence everywhere. However, with the growing adoption of Agile estimation especially in the software industry, the concept of relative estimation is booming. In many organizations where teams are focusing on Scrum-based iterative development, relative estimation is seen as a common practice. So, should Scrum teams just focus on relative estimation only or there is a place for absolute estimation as well? Let's find out the answer in this article by discussing in detail both absolute and relative estimation.
Absolute means fixed, non-variable, rigid, unalterable, etc. So, absolute estimation is the estimation that is straightforward, involving some elements of fixed time and no comparison with similar reference estimates.
Absolute estimation is seen everywhere in our day-to-day discussion. For example, if someone asks you how long it will take you to do 50 pushups, your answer will probably be that I can do 50 pushups in almost 2 minutes. Similarly, if you take your car to the mechanic and ask him when can I get the car back, the answer will be something like 4-5 hours. So, it is natural that we intend to estimate things based on time or number.
Absolute estimation is so common that it is part of estimating works in almost every industrial sector. In fact, the software industry has also been practicing absolute estimates even on long-term and complex projects.
Before we discuss what relative estimation is all about, it's important that we know how it has emerged aggressively in the past few years, especially in the software industry.
With the technological advancements and rapid shift towards digitalization in the present era, the software sector is in full swing. The demand for new software solutions is growing aggressively. Moreover, the competitive environment is also urging software firms to release new products/features at a faster pace. Owing to all that, Scrum-based iterative software development emerged that let teams release products or new features to the market earlier and get timely feedback from customers before the final version of the product is released. The iterative development model also brings with it the concept of relative estimation, which has become a popular estimation approach.
Relative implies in comparison with someone. So, relative estimation is about estimating the efforts in comparison with other lined-up or similar work. For example, let's say that it took you 5 hours to cover a 500 KM distance. Now you have to complete the same distance but this time you have to factor in the bad weather condition. So, if you now have to estimate how long it will take to complete 500 KM, then you will compare it with the previous timeframe and add some extra time for the weather condition. So, your relative estimation guess for this journey will be around 6-7 hours.
In the software industry, the teams often do relative estimates using story points. They assign story points to the backlog items to indicate the required efforts and the size. An item with the highest story point means that it requires the most effort. However, while assigning story points, they compare it with other lined-up or similar items and assign the story point through comparison. Let's understand it with the help of an example.
A team is estimating some backlog items. The members will take one item, discuss it, and assign a story point to it. Afterward, they will pick the next item, compare it with the first one and see if it requires more effort or less compared to it. This way, they will assign the story point to it. The process goes on until all backlog items are estimated. Moreover, they might also use past story points as a reference to check how accurate were estimates at that time for similar backlog items and then assign more accurate points to the current items. This way, Scrum teams utilize a relative estimation approach to estimate their backlog items.
Estimation is nothing more than a well-thought guess. Both relative and absolute estimation can provide the guess of the efforts, but the difference comes in terms of accuracy. It is witnessed that absolute estimation is a time-wastage during early product planning stages because there is limited information on which the estimation is based.
To better understand the inaccuracy of absolute estimation, the study by Magne Jørgensen and Stein Grimstad (2007) can help a lot. In this study, the researchers set up different scenarios and asked the groups to provide estimates. Below we have discussed one of those scenarios:
Two groups were given the same specification and asked to provide the size estimation. One group got that specification on one page only, while the second group got that same specification extended to seven pages. The result of the estimation was that the second group provided an almost 50% bigger estimate than the first group's estimate.
From the above scenario and the result of its estimation, it is self-evident that how inaccurate absolute estimation can be. Absolute estimation relies on the currently available information. So, the estimates are less accurate because there is no involvement of uncertainties or past troublesome situations.
On the other hand, relative estimation is a comparison-based estimation. It is oriented to estimate the efforts based on comparing with other lined-up items or similar items from the past. This way, the estimates are more accurate. However, you cannot expect relative estimation to be accurate in the first shot. You might get inaccurate estimates at the beginning, but gradually when you have more experience and reference data to compare, your relative estimates will become more accurate.
The software development framework has changed a lot over the past few years. Software firms are now preferring iterative-based development, as it's a faster way to release products in the market. When it comes to estimation, most of the Scrum teams today are using the relative estimation approach. There are reasons for that, as follows:
The first reason why teams prefer relative estimation is the incomplete information of the backlog item that hinders them from doing the absolute estimate. For example, if they perform an absolute estimate and fail to complete the task on time due to unexpected issues, then it causes distrust between the team and stakeholders. On the other hand, relative estimation gives them a chance to estimate based on their past experiences and also factor in uncertainties.
Scrum teams estimate the size of backlog items to get an idea of the required efforts instead of guessing the required time to complete them. This helps teams to have some extra time to deal with complications without stressing themselves. Absolute estimation cannot work here because the estimates will be more focused on time instead of effort. Therefore, to have better efforts-based estimates, relative estimation suits well.
From the above two reasons and other discussions made in this article, it is evident that relative estimation suits well for Scrum teams. There are different techniques teams can use to do relative estimation, such as Planning Poker, Async Poker, Dot Voting, T-Shirt Sizing, Affinity Estimation, and similar others. Scrum teams can also use absolute estimation in cases where the size of the task is extremely small and there are no chances of uncertainties. To sum up, the relative estimation can offer far better and more accurate results to Scrum teams compared to absolute estimation.
