Sunday, November 6, 2022

Effort put into estimating

I generally prefer not to estimate story points or anything similar, but sometimes we have no other option - be that because of stakeholders' expectations, development team's habits, etc. So, if we have to estimate for any reason, then at least let's not put more than a little bit of effort into this activity. I'll explain why I think so using an example which I find to be a really nice metaphor... or maybe something more than just a metaphor.

Our task is to estimate the number π. We will approach the task in a naive and simplistic way (for a good reason) and we will see where this approach leads us. For our estimation, we will use a square and a disk drawn inside the square. We will then use a few techniques to find a ratio between the area of the square and that of the disk by counting dots distributed over the areas.

Estimation #1

Even distribution of dots.

The result is not bad - a little bit above 3.

Estimation #2

Random distribution of dots.

This time the result is a little bit too high, but still useful as an estimate.

Estimation #3

Event distribution with a pattern.

This exercise uses two dots in each "unit square" and produces the same result as our previous random distribution.

Estimations #4, #5 and #6

I wrote a small Python function to simulate the random distribution and the counting of the dots. It produced the following results:

  • Estimation #4:
    • 1000 dots total, 781 inside
    • π = 3,124
  • Estimation #5:
    • 10000 dots total, 7 838 inside
    • π = 3,1352
  • Estimation #6:
    • million dots total, 785 128 inside
    • π = 3,138976

What are we learning from these examples? That putting more effort into estimating does not makes the estimates better. The number 3,04 is as good an estimate of π as 3,1415 is - after all this is an estimate.

Someone can say "Well, OK, but this is a simplistic approach, because the only thing you try to do here is to approximate the number π with a fraction". Yes, that's true, but isn't it true as well with all of our estimation techniques? They are all simplistic and naive proxies of what we are imagining will happen or might happen weeks or months ahead, in a complex system of a living development team working on a software product. So, is it maybe something more than just a metaphor?

See also