A lot of books have been written about estimations.

Before we focus on estimation on software or estimations in the agile world, let’s look how good we human’s are at predicting.

NNT has written a wonderfull book called the black Swan. In this book he explains why humans are bad at doing predictions.

To make things worse, he explains that experts have a blind spot for knowing their own weaknesses. At least people without knowledge, know they don’t know anything.

That could be a reason why estimations from non experts are better then experts.

NNT makes a difference between mediocristan and extremistan.

"In mediocristan everything is more or less the same: height, weight, calorie comsumption.

Let’s play the following though experiment. Assume that you round up a thousand people randomly selected from the general polulation and have them stand next to one another in a stadium. Imagine the heaviest planet you can think of and add him to that sample.

Assuming he weights three times the average, between four hundred and five hundred pounds, he will rarely represent more then a very small fraction of the weight of the entire polulation. (in this case about half of a procent )

And if you had ten thousand people, this contribution would be vanishing small.

Consider by comparisan the net worth of the thousand people you lined up in the stadium. Add them to the wealthiest person to be found on the planet.

Assum his neth wurth is close to 80 billion, with the total capital of the others around a few million.

How much of the total wealth would he represent 99,9 percent?

Indeed , all the others would represent no more than a rounding error for his net worth.

The variation of his personal portfolio over the past second. For someone’s weight to represent such a share, he would need to weight fifty million pounds.

In extrimistan, inequalities are such that one single observation can disproportionatly  impactthee aggregate, or the total."

 

Projects live in extrimistan.

NNT goes on to say that when we make predictions, we should also add a range.

When I start with teams, I ask them to do an exercise/quiz I ‘stole/borrowed’ from Software Estimation: Demystifying the Black Art.

This is the assignment:

For each question, fill in the upper and lower bounds that, in your opinion, give you a 90% chance of including the correct value. Be carefull not to make your ranges either too wide or too narrow. Make them wide enough so that, in your best judgement, the range gives you 90% chance of including the correct answer. Please do not research any of the answers – this quiz is intended to asses your estimation skills, not your research skills.You must fill in an answer for each item; an ommited item will be scored as an incorrect item. Please limit your time on this exercise to 10 minutes.

The questions comes from page 16 (No I’m not going to repeat them here, buy the book if you want to do the same.)

All of these figures are hard to estimate. For most of these we don’t have enough information. I send it out to a team by e-mail without further information.

Already there something interesting happens. I get no questions. Yes it’s true, 10 minutes is short, but I never tell them 10 minutes in one period. You could stop estimating, and come to me for some explaination and then spend the rest of the 10 minutes. (if something is not clear) Do you see any comparison with what happens when you ask people to estimate some software by e-mail?

What Steve says and what I find out every time I do this with a team, is that people have some internal pressure to make their ranges to small. Every one feels there ranges are too wide, even though I never had anyone have a 90% score.

A lot of managers want to put pressure on their teams to narrow their estimates, that is not needed. People already do this. Actually we want them to make their ranges wider.

It’s the whole precise vs accurate discussion.

We want the estimates to be accurate, but we use precision as a way to say it is accurate. While the more precise an estimate is, the more the chance is, it is not accurate.

All what I wrote here, is not new. And has been written multiple times.  What was new to me, was when I looked at the lowest range of the team and the highest range of the team. And now I had a 90% accuracy, most of the time.

 

Well, new is not actually true, that is using  The Wisdom of Crowds on estimations. It was new to me that it could be applied so easily on estimations.

Techniques like Planning poker tried to take advantage of the wisdom of crowds by having everyone vote. One problem I see with this approach is we still try to come up with one number. (so we loose the wisdom of crowds advantage)

One thing I advise PO and SM these these is to at least write down the biggest and the smallest number of the estimations. That is interesting to keep track of.

That is not enough, as what I will give as the right number is totally different as if I give the lowest and the highest value.

It also gives the message that we can give one right estimate, which is wrong. We can’t. if people look at it as an estimate is just that (an estimation and not exact science) that is fine to me. In most cases somewhere along the line people start to think of the estimates as commitments. Having an upper and lower limit, is one way to make it clearer that one number is not precise. It might not be enough…

Another technique I prefer these days to do estimations is relative sizing.

It’s a technique I learned from the XP Game. In the game players are asked not to estimate with numbers, they are asked to put the index card in relative size order.

What is bigger to do. Even if the tasks are totally different.

It’s only at the very end we add numbers to the estimations.

What I have noticed when I ask people to do this with real stories, is that once they have to add numbers to the stories, they all of a sudden no longer agree with the order.

When I asked why, it usually was: "they" will never accept such a huge number for this story.

That could be true, but that is not a reason to change the estimate. That is a reason to have a good conversation about the story. And see if there is no smaller version "they" would be happy with.

Kinda like with Dimentional planning.

Dimentional planning will actually bring all of these idea’s together.

With dimentional planning you think of multiple ways of delivering the sofware.

-A dirt road (with a manual workaround)

-A cobblestone road (the bare minimum implementation)

-A asphalt road (a complete and usable implementation)

This way of working is also in sync with set based design.

if something has to be finished by a certain date: you can either work on the version that will be 100% ready, or work on something that is better but have a chance it won’t be finished. Set based design says: work on both.

Dimentional planning is doing exactly that.

The dirt road is the low range of your estimation, the asphalt road is the high end of your estimations.

If you work with small iterations I would say start with the dirt road in the first iteration. You will have a very cheap version. The customer can give feedback on something real, based on that feedback you can create a better dirt road. Once you have a dirt road that goes into the right direction. (Or better arrives at the correct city) then you can start implementing the cobblestone road.

Your estimations will be much better by then.

Suspicous reader, "Yves, this takes a lot longer to deliver."

Yves: "is that so? if you create the asphalt version from day one, and you are wrong (which we usually are in a first version) it will take more time and money."

Suspicous reader," Well we know very well what our customer wants"

Yves:" That is why I started with the story of the black swan, most people can not."

Suspicous reader," what about Apple, they seems to have a good record track?"

Yves," great question, look at their history, you will see they use exactly that a first version that is minimalistic and only later whistles and bells, but the whistles and bells that everyone wants. (And they did have their misses)







2 Responses to “Agile estimations”

  1. […] This post was mentioned on Twitter by Silver Catalyst, Yves Hanoulle. Yves Hanoulle said: I blogged about Black Swans & Agile estimations http://bit.ly/a5YRy4 […]

  2. […] do set up a kanban board. – What tools should we use. – What agile methodology is best? – How to do agile estimations? – How do we start code reviews? – … Etc. These are logical questions for people new to agile. […]