Archive for the ‘Estimations’ Category

I read everywhere...
The last years, I noticed that I explain dimensional planning more and more.
I learned about dimension planning from Koen van Exem, one of the early Belgium agilists.
It’s one of these early germs of (Belgium?) agility, that unfortunetly has been mostly forgotten.

Last night JB (Rainsberger), Alistair (Cockburn) and myself  had a small discussion about it, that made me realise that I still have a nice story that I had not shared on my blog yet.

Before I do that, let me explain the basics of Dimensional planning.
The idea of dimensional planning, is that we slice our stories in different implementation dimensions.
We do this because as JB says, a lot of  clients want a Lexus by the end of the week. We might not be able to do this, yet we might be able to offer them a toyota by tomorrow, most clients love this offer till we can deliver the Lexus. (Aka very fast ROI)

I prefer the dimensional planning theory like Koen explained it to me.

Imagine you have a client that wants a highway between Amsterdam and Heusden.
You are good at making highways, so you start building right away. After a few months you are ready and you proudly let your customer use the highway. She arrives at Heusden and she does not have a happy smile on her face. You go over and ask about the gas stations and and if she liked the picknick area’s and the exits every 20 miles ect etc. Although she answers positive on all your questions she seemed to get annoyed more and more. And finally she burst out: this is not the city I wanted to get to.

You look around and notice the city sign: Heusden. Did she not want to go to Heusden? Yes she did.
Turns out there are two cities of Heusden.

After this your company and the client lawyers have long and large discussions about who’s fault it is and who will pay of the not useful highway.(If you have a good lawyer, your client will pay and then never come back…)

You could also use dimensional planning. When you do, you start by building a dirt road between Amsterdam and Heusden.

After less then a week that would have been finished and you would have discovered that you are going to to the wrong city. You say no problem, we both knew up front we would encounter misunderstandings. You look around, find the new Heusden and build another dirt road. You deliver that one after another week and wow, you discover together with your client that even that is the wrong one. Turns out there are 2 cities in Belgium and 1 in the Netherlands that are called Heusden. Who knew?
After another week, your client is happy that she has a dirt road between Amsterdam and her Heusden. (A lot faster then the original few months.)
Although she does not have all the features yet, she has already return of her investment as she can start sending cars between the two offices of her company. It’s not a great road, it goes rather slow, yet a lot faster then the previous road that had a detour of 100 km.

The day after you delivered the correct dirt road, you started working on a cobblestone road.
After another 3 weeks, you deliver that one.
You can also create a tarmac or asphalt version and a highway version.
Yet in a lot of cases the clients don’t want to highway version another more when they already have the ROI of the previous versions.

Because we all know that when we ask a customer if they want a highway they always say yes, and developers love working on all the features of a highway.

Yet going back to the car example as JB said so nicely yesterday,  most people would prefer a Lexus over a toyota, except if they need to pay for the Lexus, suddenly a toyota (or even a lada -Thx Rik D’huyvetters *2-) is enough. Just like not every developer likes to pay constant attention to all details the way a Lexus demands.

Reader: Well Yves, isn’t it pricy to deliver 3 dirt roads, a cobblestone road, a tarmac and a highway?
Yes it is more pricy then just a highway, yet as we all know errors are made and delivering all that is cheaper then delivering 3 highways, as we almost always seem to do in product development.
Reader: Oh but in my methodology, we prepare so much that we never make mistakes…
If you are sure and you take that risk, be my guest. Even if you are correct (which I doubt will happen in 100% of the cases) I’m pretty sure that by the time you have started creating your highway, a lot of customers have already changed their minds. And our dirt road projects are delivering ROI already after just a few weeks, months before you even have started.

Reader: All nice theory Yves: how does that work in practise?
Ah glad you asked, I almost forgot, I started this blog with the promise I made to JB to blog about one of the nice real life examples.

A little disclaimer, I did change a few details of this story, to protect the client.

This is large company that already has a website, yet the website is totally in a demilitarised zone of the company network. They have created a small thing they are going to sell over the web.
The CFO was a big supporter of this product and wants to see the websales on a continuous basis.
To do that, they would need to breach to security zones and insert the sales data into their SAP.

At such a large company, that is a large project that will take 6 months of development and to prepare, we will start with meetings with at least 20 people in the room. (Security experst, SAP experts, webdevelopers and then lots of  managers all the way to the person below the CFO)

At another meeting, the CFO shares concerns about lacking visibility of the sales progress for the pet product during the first crucial 6 months. I propose a temporary side projects, using dimensional planning. (where we consider the highway version the other project. )

The dirt road version:
Every day, we generate  a pdf report on the webserver that we put on a floppy disc. (Remember  this server was disconnected from most of the network.)
Everyday we print the PDF and bring a copy of the papers of the sales to the CFO office and have an intern typing in all the data into our SAP system.
The PDF report is created by one of our developers on the same day as the product goes life. By the end of the day, we already have the data for the CFO.
First problem noticed: the CFO wants something extra, something our website did not ask our customers buying the product. The developer that had proudly shown the report herself to the CFO, went back to her desk and less then 30 minutes later, the website asked the extra info, and the new report was generated. (Missing the data of the first day.) Right in time for the newspaper article that was published the next day, when a large number of customers buy the product.
The next day, while these numbers come in, our intern tries to add the data to SAP. We discover our second Heusden. Turns out that we were targeting the wrong SAP table.
This fix takes a few days. The CFO keeps getting his report, yet nothing in SAP the first week.
By Friday of the first week, our intern is able to upload data.
Yet it’s very boring work and is totally not scalable. (We have a few thousands sales the first week.) Time for our

Cobblestone version:

This time we are going to generate the report in a cvs format (Remember, this is before xml was popular.) Every day the first developer arriving at the office, wil physically go to the webserver, generate the report and copy it to the floppy disc.
The same developer will take the disc and upload the data to our SAP system.
This version is more scalable, no matter how much we sold our product the previous day, the action for our developer is the same. Even in this version we have a small glitch: one of the fields is marked as text instead of number. (Just a normal bug).

It’s a manual action every day, not automated and is only updated once a day (for the previous day.)

While this solution is in place, the meetings continue for the highway version. At the end of such a meeting, I ask the collaborator of the CFO, how they use the data and if they are happy with the numbers. Almost by accident I discover that the CFO is only looking at the data on Friday.
(So not on a daily basis ) and he even does not care that he does not see the full sales of the day/week.

Luckily I have a meeting with this same collaborator and the CFO the next day. We talk about the progress of the highway project and how it’s really blocking people from working on a high priority legal project. I gently propose that we might keep the cobblestone project in place for now, and put the highway project in hibernate. A lot of people at this company are unhappy, because they had hoped to work on this super duper cool project. The security officer on the other hand is very happy, because she can keep the webserver in the safe zone, without temporary breaches.
In the end, the company saves 6 month of development for a highway, that is putting their network at risk and that would not really be needed.

A few years later I meet the CFO who tells me that the highway project was probably a little overboard as the product they sold online, never got any sales that even came close to what they would have had to spend to deliver the highway project. And thanks to the dirt road project, they discovered very early that the missing e-mail addresses of their customers and that turns out to be the best investment every. This e-mail list has helped them the next years to up sell some of their services to these customers and that has saved the company from going bankrupt.








This week I was ALE 2011. To remember and share my experience I will write an improvement game

What I like about ALE 2011:


  • I forgot about the failure cake

What I would like to see improved:

  • More people using “The Law of two feet” when they think they can have more value somewhere else. (It’s not restricted to the Open space sessions only)
  • Oomps (Official One Minute presentations about the upcoming talks)
  • Closing oomps: at the end of the day participants talking back what they learned from all the talks
  • an organized way of sharing rooms
  • An organized way of sharing Taxi’s, from and to the airport
  • A date more families come
  • the children room in a more central place
  • the children report back what they have done as part of closing oomps
  • the family program is on the official program (no second citicians)
  • we have a book swashing activity
  • we have bar activities (like agile quiz etc)
  • all groups of dinner with a stranger are smaller then 10
  • I would like to see less “Agile EGO” (We are agilist so we are better then the rest of the world) and more use of prime directive in everything we do.
  • People are funny without cynism & sarcasm
  • everybody understands what it means to have an open space conference
  • More butterflies
  • More Bees
  • No passive aggressiveness against people not from our community
  • a world café
  • more developers
  • more C-level people
  • a book shop
  • make it clear if participants will receive a notebook or not
  • We have 24 hour wifi
  • The Coffee and the rooms are on the same floor
  • the toilets are on the same floor
  • We should have some room for longer sessions (games?)
  • We should help new presenters
  • We should encourage speakers to do dry run’s

Personal improvements

  • I should have used paircoaching on the coffee mugs instead of so that more people understood this was a promoting of an idea and not a company
  • I buy less mugs then participants
  • I can withhold from jokes about Americans (Sorry Brian I was really happy you were at ALE)
  • I listen more when I meet awesome people
  • My family joins ALE 2012
  • My family is active in ALE 2012.
  • My phone keeps working during the conference
  • I check the feedback from my session at the door…
  • I should have thanked the organizers more…


My improvements are worth 1 out of 10 for me.(This means that ALE receives a 9 out of 10 )

This is a cool video on how to use a kinect with your wallboards.

Now as you know I am not a big fan of electronic boards, but with tools like this, you have the best of boths words.
Check out their website for more:

When will you implement this?

My ideas:

  • use this in combination with a real (paper) task board
  • use QR codes to recognise the stories.
  • Use this with a projector.
  • Use this in the teamroom to have people make changes while sitting down (wild idea that needs more thoughts..)

Agh I really want to try this out

About 2 months ago I started my “Who Is” serie. The idea was to ask a a bunch of diverse people some questions and publish one set of answer every week.

The first mail I send out, I did not got any answer for a few days. I was not sure if it was a good idea or not, so I send the questions out to a few more people. Then I thought it is almost holiday. I will be gone for a few weeks, and I wants to be sure I can schedule answers while I am gone. (And I don’t want to take the risk that I don’t get any answers for the rest of the holiday period.) So I started to send out my questions to some more people.

When people replied, I started looking at the last answer (who should I ask next) and send out questions to these people. When people told me, I need some time to think about these people I asked hem, could you already give me new name(s).

I published the first set of answers from Lisa Crispin 10 days before my holiday. During my holiday I started to get lots and lots of answers. I needed a tool to keep track of who I invited and who accepted. I created a spreadsheet to write down all the names of people I invited. When I started to record them, I quickly realized I had already invited lots of people.

By the time my holiday was over, I had 76 people invited, 52 people had said yes (2 said no) and + 30 had written an answer. I started to add a publication date to my spreadsheet.

Somewhere along the way I had decided that I would schedule answers “in a first answer, first published” order. I communicated that to the next people I invited. (I did not do that to the first people I invited.)

When I received a new set of answers, I read the answers (I just love what people are doing with the questions.) Then I thank the person for his time (as I know that answering these questions takes a lot of time for most people.) And I tell them when their answers will be scheduled. More and more I started to feel guilty, as I had to tell people in July that they would be published in October, November etc…

Last week I received an answer from a person I admire a lot. I invited her before my holiday. I had told that person it was ok to answer after my holiday as I already had answers for the next weeks. I forgot to tell her about my “first come first serve policy”. By the time she answered, I had people scheduled until February 2012. I told her, the probably publication date. She was mad. Really mad. She had spend part of her holidays writing the answers, rewriting it a few times. The result was one of the most touching answers I received, very personal. She was mad because she found my release schedule ridiculous for an agile coach. She was right.

Lets look at this project:

  • I had a weekly release schedule.
  • A large project backlog of people (76)
  • A velocity of one

I realized I treated my project backlog all the same way: from the moment a name got added to my backlog I started to work on it: that is I send an e-mail asking that person to start working on it. In my defense I had an almost unlimited team for working on the backlog (one person a story feels unlimited for me.)

Start to see some links with agile projects? Wait it get’s better.

Not only did I have an unlimited team, they also started to deliver very fast. (That’s is why I now have 39 answers.)

I said I had a velocity of one, but I have 39 answers in a couple of weeks, shouldn’t my velocity be 39/nr of weeks? Aha great question mr Watson. To answer this question we have to look at my definition of done. When is a story done? It’s done when it is delivered to the customer. When is it delivered to my customer. Well the customers of this blog are my readers, yes I ‘m talking about you. The stories are delivered when they are published on my blog.  Aha that shows a a glitch in my explanation. I don’t have an unlimited team. I actually have a bottleneck. Remember TOC, there always is a bottleneck. Find it. And eliminate… Oh wait I am the bottleneck.

I’m publishing only once a week. That is a choice I made. Publishing more would be lot of work for me. Mmm when I coach teams I tell them, when it’s hard do it more often. Ok maybe I should publish more often. So I asked my agile friends on twitter (and in person)

Turns out that my customers liked my publishing limit and actually asked me to keep it.

Ok. That is a dead end. What else can I do to solve this problem?

Let’s see what is the problem again? The time between the receiving of the answers and the publication is too big.

Let’s have a visual look at the work:

Todo Asked Said yes Answered Published Total
46 24 13 30 9 117

I wrote this table as in Kanban. Every column represents the Work In Progress.

(Except that I added the total at the end)

Aha Visual Management helps again. Clearly the biggest block is in publishing.(Tell me something I did not know.) I already know that publishing faster is not an option.

Ok so now you are doing Kanban, so what would David Anderson do? He would limit the work in progress.

I can’t stop people from saying yes.

I can’t stop people from being added to the TODO list (really I can’t because it is part of how the answer that I expect people to give.)

The only place where I can limit the work in progress is Stop asking people to answer questions. (For clarity I did not write: ask people to stop answering questions.)

As you can see I have already 46 more stories ready on my backlog (they are ready when I have a name and an e-mail adres.)

For all the people that have answered the questions, I’m sorry the time between your answers and my publication is so long. This was in no way my intention to disrespect the work you did to answer the questions.

If I already asked you, and you haven’t answered, what should you do?

Today (2011/08/18) I have a publishing schedule until 2012/04/10. This means I ‘m not urgently waiting on your answers.

You can answer at your own pace, write the answers when you have time.(I do keep my scheduling based on first come first served.)

A big thank you for the person being mad at me at pushing me to blog about it.

(You know who you are)


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)