Agile estimations — part 1/2. Why should we do relative estimation ? Or even estimations at all ? That’s one of the tough question I’ve had in every single team I have helped as a Scrum Master or Agile Coach. I’m sharing some tips to convince your team that it can be useful and efficient to estimate the work to be done.

Why should we estimate?

This question is in my opinion not the toughest one the Scrum Master has to answer. Don’t take scrum teams for naïves, they know perfectly that stakeholders have some expectations about visibility on team’s work, and they want to know what’s the release plan when the expected feature/impact/value will be delivered.

Now, what we really need to work on with our stakeholders is the deadly iron triangle of “time, scope and resources”. I intently don’t include quality, as there should never be negociations about the level of quality delivered. In an agile world, resources and time are fixed : we have a stable team, our time to deliver is finite, and the cadence is set by our iteration duration. What we can adapt is actually the scope of our product. For that, we need to be able to announce our stakeholders the approximate size of the chunks we can bite every period of time. That’s how I approach estimations.

But don’t take me wrong on this. I also believe that estimations are not the things that bring value to our stakeholders, and they also need to understand that. When I start estimating with a team, I try to make sure that all stakeholders accept estimations for what they really are : wrong. Our goal is not to spend a lot of effort in the estimation process to be as close as possible from the truth. In a VUCA world (Volatility, Uncertainty, Complexity, Ambiguity), we accept that estimating with a high level of precision the time we’ll need to achieve a task is a waste of this time.

To my opinion, the actual valuable output when using relative estimations (and specifically tools like poker planning explained below) is to share a common understanding of the product backlog items we estimate. When we discuss and try to estimate these items, we will share our points of view on their complexity, and improve alignment by detecting where we don’t have the same understanding. And that’s where we should spend time, discussing, aligning, understanding. The figure in output is merely a byproduct of this valuable process.

Why should we use relative estimations ?

Relative estimations are estimations that are not based on an absolute scale (duh), but on a relative one. To size relatively some items, we’ll not take one and place it on an absolute scale, like we would do by weighing something, but we’ll compare it to something that we already know : is it bigger, is it smaller? By how much?

Let’s take an example here :

• Can you tell me how many inhabitants there are in Clermont-Ferrand, France?

Most certainly, if you haven’t lived there, your estimation will be quite wrong or at least very uncertain.

• Now can you tell me if there are more inhabitants in Clermont-Ferrand or in Paris?

Even though you don’t know how many inhabitants there are exactly in Paris, you might have clues that it is bigger than Clermont-Ferrand.

Our human brain is simply not suited for absolute estimations.

Let’s add another level of details to this estimation : if I give you this table of relative estimations that have already been done, is it easier to place any city ?

Can you place Singapour? Beijing? Manchester? München? …

We won’t have a very precise estimation in output, but hey, if you’ve read the first paragraph you know my opinion about these…

Why should we use the fibonacci sequence ?

Let’s take another example : if I hand you a weigh and I ask you to tell me how much it weighs, you will be embarassed and will take a risky guess.

Now if I give you 2 weighs of 1kg and 1,1kg and ask you which one is the heaviest, well it’s not going to be an easy guess either, since the two values are too close to be differentiated clearly, their gap being only 10%. But if I give you 2 weighs of 1kg and 2kg, it will be much easier, the gap between the 2 values being now 50%.

And that’s exactly why we do relative estimations with the fibonacci sequence as a scale. The levels of the Fibonacci sequence scale are obtained by adding the two precedent levels : 1, 2, 3, 5, 8, 13, 21, etc.

So we have globally always the same percentage of gap between the levels of this scale (2/3 = 67%; 3/5 = 60%; 5/8 = 62%; 8/13 = 62% and all the next ratios tend to 62%). So you brain knows that the different levels of this scale always have the same distance and it gets easier to determine if what you’re estimating is in one level or in another.

How can we reduce the risk of getting wrong estimations?

That’s one of my favourite part, and that’s one of the most important thing about estimating in my opinion. To be able to estimate “correctly”, we have to get a good idea and overview of the problem we need to fix, and its different components.

But first, a very important disclaimer : estimation are by definition… wrong! So take them as what they are intended to here : a tool to help you plan and adapt your plan, not a prediction of the future. And most important thing : explain your use of estimations to your stakeholders!We’ll come back to that in the second part of this article…

The relative estimation will take into account and compare several elements :

• complexity : is the problem very complex ? are the technical solutions needed very complex ?
• volume of work : is there a lot to do to fix this problem ? (it could be a large volume of very simple things to do for example)
• risk/uncertainty : is the problem we try to fix well defined ? are there parts of shadow in the technical solutions or in the problem itself ? Are there questions that are not answered yet ? Is there a risk on the feasibility of the solution ?

Very often, the team will have different point of views and different elements of knowledge and experience about these problems and how to fix them. And that’s where the poker planning comes into play !

Doing a poker planning will make the team share the different pieces of info and knowledge they have about the job to be done, clarify any misunderstanding and align on the same approach.

So the output of the poker planning is double :

• you get the estimation for Product Backlog Items on your team’s dedicated relative scale
• but most importantly, and that’s the most valuable part, you get alignment, transparency and clarification on the product Backlog Item content and the work to be done by the team to answer to the Product Backlog Item

In this article, we’ve seen why we do estimations, why relative estimations are better than absolute ones, and one tool — the poker planning — to make estimations.

Some things are still missing here, so (yay!) there will be a second part about how to use these estimations in actually building a plan and communicating it to your stakeholders.

If you liked this article, don’t hesitate to follow me here on Medium or on LinkedIn. I’m always happy to discuss the topics I’m writing on and to receive feedbacks. Thank you !