Conventional or traditional way of project delivery usually has one big fat release once the project is complete. In this case usually any work item has to fit into the timeline and the basic thought process behind the estimation is to check the impact on the timeline and the budget. The natural question to ask in such a scenario is – How much time will we need to finish the work? This question is usually answered in terms of hourly estimates or man days which depicts the commitment of the team’s effort to finish the work.
When teams adopt agile ways of working, where the work is broken down and delivered incrementally and iteratively, the thought process changes from “how much time” to:
How big is the work?
Can we fit the work in the sprint?
When it comes to answering these questions, absolute estimations like hourly or man days may not be the right fit. We may need to express the work size with respect to complexity and uncertainty. This is where relative estimation comes into picture. This blog aims at answering a few questions about relative estimation in agile like:
What is relative estimation?
Types of relative estimation?
Role of relative estimation in agile?
Advantages of relative estimation
What are a few Relative Estimation Techniques?
What is the relative sizing estimation technique in agile?
What is Relative Estimation Techniques?
Relative estimation is an approach of estimating one piece of work by comparing it with another. It is not a definite hours or man days which signifies how long the work will take. It refers to the size of the work by comparing effort, complexity and uncertainty with another piece of work.
Example: If we assign 1 to a size to a grape, how many grapes is the size of an orange?
It may sound easy but confusing at the same time. Let’s see how it works:
First set a bench mark with a very small piece of work which is rather simple, less effort taking and limited uncertainty. This will act as a base work items for reference
Then all the other work items are compared to the base work item in terms of complexity, effort and uncertainty and then estimated
Teams can use methods like fibonacci series, T shirt sizes to represent the size of the work which does not usually tell how long will the team take to complete. Rather represent the size of the work based on the complexity
Agile ways of working concentrates on responding to change and being flexible, continuously pivoting and adapting to changes. This type of environment requires the change of thought process in terms of estimation. Below are a few reasons why relative estimations work the best in agile environment:
Shift in focus from time to size because of iterative and incremental delivery
Uncertainty in the requirements because of the changing requirements
Cross functional team nature for whom precise time estimation could be a challenge
Need for quick estimation rather than detailed and precise estimation
Reducing the gap with non accurate estimation because of difference in experience
Focussing in just enough planning versus detailed planning
Types of Relative Estimation Techniques in Agile
Relative estimation is the approach in which one piece of work is compared with a reference work item to size it. While the ideology of relative estimation is constant, there are different frameworks and techniques to achieve relative estimation. Some of them include:
1. Story Points / Fibonacci Series
Story point is simply a number given by the entire team which signifies the size of the work. Story point estimation is a relative way of estimation i.e teams compare one work with the other and then size the work based on the 3 factors mentioned below.
Effort taken by the entire team
Complexity of the work
Uncertainty in the story
A smaller story point signifies the work for the team is small and a bigger story point signifies that the work is big in size for the team. Story point estimation uses Fibonacci series to estimate a work. The traditional Fibonacci sequence is 1, 2, 3, 5, 8, 13, 21 and so on, with each number the sum of the preceding numbers. Agile Team uses modified Fibonacci sequence of 1, 2, 3, 5, 8, 13, 20, 40 and 100 for estimation. The Fibonacci sequence prevents estimates from being too close to one another.
Skip to content 
