Archive for June, 2010

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)


At XP2010 after I played the 4.01 version of the leadership game, I told someone (sorry I forgot your name, shame on me), I would put a link to the ESSAP video’s.


This one with a part of the explanaition looks like the most interesting (based on the number of hits.). Personally I’m not sure it’s interesting without knowing what happened in this particular game. (You could watch all the other videos to try to understand that,…)

Feel free to tell me if it is of any interest to you…

For the last 5 years, I was wearing my t-shirt at all the conferences I ‘m  going (as a speaker or participant). At every conference there are at least a few people asking me what PairCoaching means.

Some think the logo is about me coaching pair’s (which is logic as I do a lot of things with my father, who does that kind of work. Others think it is about me and my partner coaching people together, which is logic as we have presented together.)

It always ends in a talk about paircoaching and sometimes a few more people willing to try out to do more pairwork. Mission accomplished…

At XP2010, I wore a shirt with burned wholes in it. I received a lot of questions about that.

The shirt is publicity about the talk I’m doing at Agile2010:

What I learned from burning down my house.

When people hear about the talk, they think it is a fake story. I wear the shirt to make people aware it is a real story. 1st August 1991, I (accidently) burned down the house I was living in.
I learned a lot in the next year about myself, my parents, saw the difference between so called friend and real friends etc…

Our talk at the conference is about the book “The sense of urgency”, the story about burning down my house is our way to tell it.

If you compare a picture of me wearing the real fire shirt I wore it at xpDay Benelux last November and the way I looked in 1991, you see another difference.

I had long hair in 1991. Sometimes dedicated actors become really fat or thin or grow long hair for a movie.  I decided to do the same and let my hair grow for my talk at the conference in Orlando. It won’t be that long as in 1991, but should give you an idea.

(Please hope with me, it won’t hurt me at my current client.)

Every year there is some kind of good cause at the conference and the agile alliance hopes people will give some of their money to.

I decided I will have my hair cut at the conference (sometime after my talk).
People can cut a part of my hair if they donating money. (Something like 5 dollars for each time you cut a piece of hair and  10 if you want to take it with you;-) …)
Update: I have contacted the Agile 2010 organizers,  not only have they acceped my proposition; Bob Payne invented a cool name for it: “Locks of Love”

Today at XP2010, I will be playing our leadership Game.
Special for this conference, I created a new version of the game.

The leadership Game V 4.02.

This version is now a zip file containing 16 different pdf files.

This makes it a lot easier for trainers that want to print only the documents for the players.

The version also contained a first translation of a PairCoaching text.

Based on different feedback, I have updated the discription of the game, so that it is easier to lead the game for people who have never done this before.

(Although I strongly advise you only play the game if one of the trainers has already played the game.)

The game is available as creative common 3.0 Atribution Share Alike, see leanpub link below

Feel free to join the agile games group

Update:I added the Agile Games google group and the GameStorming Book to the game
UPDATE 2013/07/02: since today the book is available (for free) on @leanpub: