The underlying idea of estimating User Stories on relative complexity

I noticed that a lot of teams that are new with scrum has trouble understanding the underlying idea of estimating items relatively from each other. The fact that a consensus needs to be reached, does not make it easier unfortunately.

So how is this done? When you ask Google, you will see all these kinds of discussions and debates with no clear answer. Or it is about the basic of applying planning poker etc.

Because of this I have decided to explain it in a more visually way and software development related. Hopefully it makes more sense by the end of this blog. ;-)

Some given information:

We are going to estimate how long it will take to finish a 600 and 1200 meter track.

In able to do this estimation, we need four brave runners. We will be using the Fibonacci sequence to estimate.

Sprint Planning Meeting:

As track coach I will be asking each runner how fast (in this example we will be using time, but later on you will see that time is going to be irrelevant) they think they can finish the 600 meter track.

Here were their responses:

Eric        : 2 min.
William  : 2.5 min.
Brad      : 4 min.
Kenny    : 6 min.

These estimated times can be based on all kinds of things. In Agile estimation we try to base the points on effort, complexity, risks and uncertainties.

I think we can all agree that there is no point here to argue about the time, right? There is absolutely no point for Kenny to convince Eric that running a 600 meter track will take 6 minutes instead of 2 minutes. This because it depends on all kinds of factors such as fit, body weight, experience etc.

This time I ask the brave runners the same question, but now for the 1200 meter.

Again the results:

Eric       : 5.5 min.
William : 7 min.
Brad     : 7 min.
Kenny   : 15 min.

Again, there is no point for 1 runner to convince another runner for to the same reason that I have stated before.

There is no argument which will result in them settling on the “right amount of time”.
They can however agree that there is a relationship between the amount of meters (factor 2) and the actual time that is needed to complete both tracks. (probably +/- factor 2)

And that is the level where consensus can be achieved!

So if we introduce some scrum terminologies such as stories, then the 600 and 1200 meter trail can be seen as stories.

Again, although the joggers cannot agree on the time that is needed to finish a 600 meter track, they can however agree that 1200 meter will take them approx. twice the amount of time. So if we translate this into the Fibonacci sequence, then story 1 (600meter trail) could have 2 points while Story 2 (1200meter trail) will have maybe 5 points.

Here you have it... relative complexity estimation in team consensus. In this example I gave the first story 2 points and the second story 5 points. It is not about what the individual point represents, but how they are related to each other.

Conclusion:

Don't try to come to a consensus like this (because it is impossible)

Instead do this: