Relative Estimation

In a traditional software development method, estimations are done in absolute number like hours or days. In this approach, by applying the Work Breakdown Structure, a big project is divided into small tasks and each task is estimated in hours. These estimates depend on the skills of the resources.

Estimation of technical tasks in absolute number is not always easy. Sometimes for a technical task, debugging will take 6 hours but the actual code fix will be done only in 10 minutes.

Relative Estimation could be useful in estimating complex tasks. To understand more on relative estimation, let’s take an example of buckets mentioned in the picture below.

If we ask how big is the first bucket and how big is the second bucket (absolute estimate)? We may not answer this question in absolute numbers. But if we ask the question, “How much bigger the second bucket is as compared to the first one (relative estimate)?” Usually we will be able to answer the second question more quickly and in a better way. It is better to use the relative estimation technique for estimating complex tasks.

Here are a few more examples of relative estimates.

• Australia is about the double the size of India.
• Canada is three times the size of India.
• Canada and USA are of the same size.

Relative estimates do not have units. They are just relative numbers. In Scrum these numbers are called Story Points.

In Scrum, Fibonacci numbers are used for relative estimation. What is Fibonacci numbers? Fibonacci is a series of numbers where next number is calculated by adding the previous two numbers.

Fn = Fn-1 + Fn-2

Here is an example of Planning Poker Cards (Fibonacci numbers) used in Agile Estimation

One may ask why Fibonacci number? Why not linear numbers?

Let's take an example of a Duster of white board. If we ask our team to estimate the size of Duster in inches, we will get answers from different people in a close range of 5 to 8 inches. After some discussion, the team may agree on 6 inches. But if we ask the same team to estimate the height of the roof of our meeting room in inches then the estimates might vary by large numbers. Some might estimate it as 80 inches whereas some might estimate it as 120 inches. But if we ask our team to use the Fibonacci numbers mentioned above then most of them will pick the number 100. Fibonacci numbers are more suitable for estimation of large tasks where we don’t have enough details on that task.  

One important point to note in Relative Estimation is that Relative Estimation numbers does not change by applying more skilled resources or by using tools to accomplish tasks. Let's play another game to understand this concept.

Add caption

Let's assume that you have three piles of stones of different size as given in the diagram above. Now let's estimate the relative size of a single stone from the first pile. As it is a small stone and there might be even a smaller stones, we can estimate the size of this stone as "2". Now consider the stone from first pile as a reference stone and estimate the relative size of stones from other two piles. After some discussion we can agree on the size of each stone as 5 and 13 relative to the size of a stone from the first pile. The total size of all the stones is 10*2 + 3*5 + 2*13 = 61.

Now in the first week a team has been given the task of moving all these stones by using their hands from one part of the city to other part of the city. Resource has to travel on foot. Probably the team will move all the stones by the end of week one. The actual efforts completed by the Team would be 61. This number is also called the Velocity of that team. 

V1 = 61 

Velocity - Total number of Story Points of all the stories done per Sprint. 

Now in the second week the supervisor asks the team to increase their productivity. In this week he gave them an additional task. Once the team completes moving all of the stones from these three piles then the team is asked to move back these stones to its first place. In this week, the team is allowed to use skilled resources as well as some tools. Now the team has knowledge of the first week as well as the tools and skilled resources. So in the second week the team will achieve higher number say 85. 

V2 = 85

In the third week the team is allowed to use some vehicle for transportation along with skilled resources. In this week, the team will achieve even higher numbers. Let's assume it as 153

V3 = 153

In this example, the size of stones does not change by the application of skilled resources or a transport mechanism. It remains the same. The change is in the total productivity numbers achieved per iteration i.e. Velocity.

As you see in this example we do not have to re-estimate the size of these stones for each iteration Also while estimating, we are not estimating the single “Time Value” to complete the task. Time value comes into picture by combining the Size, Velocity and Length of Sprint.

In real life software development, when the team is doing relative estimation then it does not matter whether they have prior experience of doing similar work or not.  As  you get more experienced or more skilled resources then you will achieve more velocity. Relative estimates remain the same.

Planning Poker Game in Scrum
Now let's discuss the steps of the game of Planning Poker used for relative estimation. 

Steps for the planning poker game

1. Select a reference story from the Product Backlog and estimate it in terms of Story Point.
2. Select another User Story from the Product Backlog for estimation
3. Understand the story from the Product Owner
4. Each person estimates the size of this User Story relative to the Reference Story using poker cards
5. Everyone shows their cards at the same time.
6. If estimates vary significantly, high and low estimators explain briefly.
7. Repeat up to three times or until team agrees to  the estimates
8. Pick a number that everyone agrees upon
9. Repeat this process for all the User Stories from the Product Backlog.

The important point over here is the resulting discussion.

Why Planning Poker Works?

• Those who do the work, do the estimation
• Team member has to give the reason for his estimation
• As team of resources do the estimates, it leads to more precise estimates.
• Each team member will be heard