Many Companies find it hard to estimate using relative size rather than absolute number. This may be due to lack of understanding or due to lack of discipline. The topic explains the reasons for choosing relative estimation as opposed to absolute estimation.

Why Estimate at all ?

  • To identify the Release date of Project if you have the team velocity handy.
  • Identify the Clarity on the Product Backlog

Why relative estimates?

  • People find relative estimation easier than absolute estimate. It is always easier to comparatively talk about the size of a small container versus large container. We would generally call it as double the small one.
  • People do not have to re-estimate relative sizes with every small change.
  • Story points is ideally the way of estimating in agile.  Most teams use a Fibonacci sequence similar to 1-2-3-5-8-13-21-40-100. The reasons are simple:There is nothing called “double than” in Fibonacci hence, a resulting decision has to be taken comparatively while estimating. Bigger the difference the greater the gap between them and hence needs a collective discussion

Relative estimation using story points mainly caters to three areas:

  1. Amount of work
  2. Complexity
  3. Risk or uncertainty

How does relative estimation work?
I like to explain estimation with a picture of some stones. Imagine you have three piles of stones:

Let’s say a single stone from the first pile gets the number “2” assigned (well, it is the smallest stone we see NOW, but who knows if there will be a smaller one at some point in the future…?). Now we ask the team how big a stone from the second pile is compared to a stone from the first pile. They will discuss it and come up with a number. Probably “5” in our example. The same procedure follows for a stone from the third pile, which will probably result in a 13. Note that we didn’t ask what we will do with the stones, yet. We are just discussing their sizes. We also didn’t discuss who will deal with these stones. It doesn’t matter when doing relative estimation.
As you can see, we have ten stones in the first pile, three stones in the second pile and two stones in the third pile. These constitute our “backlog”: 10*2 + 3*5 + 2*13 = 61

So our total backlog has a size of 61. That was easy, but we didn’t do anything with the stones yet.
Imagine my boss to be a nasty person. He tells me that he wants me to carry all the stones from one end of town to the other with my bare hands and without any tools. He also tells me to carry them back once I moved all the stones, so we have an infinite backlog. We agree on a Sprint length of one week.
I have no idea how long it will take to relocate all the stones. So there is no connection to time, yet. When I start carrying the stones around, it will take me the whole week to move all stones from one end of town to the other. So I moved ten small stones, three medium stones, and two big stones within one Sprint. This results in a velocity of 61 (the sum of all sizes completely moved within the Sprint) for the first Sprint.

Velocity1 = 61

My boss then forces me to move the stones back and forth every week. I start to grow some muscles. This does not only look great but also increases my velocity since I manage to move the stones back AND forth within one week. So I moved twenty small stones, six medium stones, and four big stones within one Sprint. The new velocity is 122.

Velocity2 = 122

The size of the stones did not change by me having muscles. What changed was the speed by which I moved them.
Now imagine my boss having a good day and allowing me to use public transportation. I now manage to move all stones back and forth twice within a Sprint, which results in a velocity of 244.

Velocity 3 = 244

The size of the stones did not change by me using the new framework “public transportation” or by me having carried so many stones within the past Sprints. What changed is my speed doing it.
As you can see, I do not have to re-estimate the stone size. I also did not estimate a single time value, e.g. how long it takes to carry a small stone from A to B. The time aspect comes into play when combining size estimates with velocity and Sprint length. So my boss is able to judge the amount of time it will take me to move any amount of stones as soon as he knows my current velocity.

This is true in the software development domain as well. When estimating in relative sizes, it does not matter if you have done this type of work a thousand times before, if you have fancy new tools, if the experienced or the inexperienced person will do the job.