The PI constant in software estimation

Already in 1975, Fred Brooks suggested in Mythical Man Month, Fred Brooks that you should triple any developer estimation. And reading blog posts, talking to fellow project managers and stressed IT managers, we all know that this is still valid. At the same time all these project managers and IT managers have a hard time accepting this. But from now on, you can refer to the mathematical formula of estimation. We all know it.

C=d*PI

Project Management Estimation = Software developer’s estimation * PI

Yesterday, we discussed this over lunch and one of the bright developers at TUI Nordic said it was the PI factor which wasn’t considered in project management.

 

 

If we see the problem as the circle we could say that we cover the problem by travelling from one end of the circle to the next. And that is what developers estimate. You could say that they are estimating the diameter.

But when they need to complete the task they have to take the route around the circle. Not only do they have to take a longer trip to reach the other side of the circle, they must also complete the whole circle and that was never in their estimate. You have setting up development environment, merging, build script problems and all that stuff which you never considered. That is the circumference of the task.

You cannot argue PI, can you?

Why don’t your estimates improve?

One question I often get is why the estimates given by developers are so bad. Why they don’t become better.

If you look at what people have estimated for the longest time, one guess is weather. I can imagine early humanoids taking a glance at the sky in the morning, estimating if this is a good day for hunting or what ever. So, our weather for casts should be great?

Well, that depends.

Having just visited Greece this summer, I became after just a couple of days an expert on weather predictions for Rhodes. It’s hot, warm and windy and when I look at the for cast for the upcoming week, I think my guess is as good as the pro’s:

But I live in Sweden and if I’m going to make an estimate of the weather for cast for the coming week, my guess is probably bad. The weather fluctuate more in our temperate climate.

 

So, when you think that your developers never “learn how to make accurate estimates”, think about the surroundings. Is the system in a temperate climate or is the weather steady as in Rhodes?

Another important lesson is that estimates are given at a specific moment. If I’m going to guess the weather in Stockholm August 13th 2010, my guess will be a pure guess, since I have no idea of the weather situation then. I can make a better guess about August 13th 2009, since that date is pretty close. So, even if you can make a prediction, this will change over time. This mean that an estimate concerning size of a task is valid just then. A month later, when the systems have changed a bit, that item can have become more or less expensive. So, don’t get upset with that developer because he gave you an estimate a year ago and he won’t hear about that today. If you want to place yourself in his position, consider the task of “getting ready in the morning”. Imagine yourself being asked that question when you are a 27-year-old without kids. Do you think that your estimate of getting ready in the morning in that situation is valid three years later when that 29-year-old has a child which goes to daycare. Just like our situation becomes more and less complicated, so becomes the situation for systems.

So, for how long is an estimate valid? Well, that is something which differs between systems and organizations. So, this you need to find out for yourself.

Why Estimate is a bad word

What is an estimate?

According to Dictionary.com the verb means:

1.
to form an approximate judgment or opinion regarding the worth, amount, size, weight, etc., of; calculate approximately: to estimate the cost of a college education.

2.
to form an opinion of; judge.

and the noun means

4.
an approximate judgment or calculation, as of the value, amount, time, size, or weight of something.

5.
a judgment or opinion, as of the qualities of a person or thing.

6.
a statement of the approximate charge for work to be done, submitted by a person or business firm ready to undertake the work.

So, why is that a bad word? Well, I don’t think it’s really a bad word, but in the case of software development, the use of the word results in some serious problems.

Case 1: A developer leaves a task unfinished, that is not according to Definition of Done. The reason is that he’s run out of time according to the estimate so he drops it or finish it with lacking quality.

Case 2: A developer starts working on “something else”. The reason is that he finished what he was supposed to in less than the estimated time and felt free to spend the rest of the time with that other stuff.

Case 3: A project manager gets upset that a project is late. The reason is that he feels that the project is late because things took longer than the estimates.

So, why is estimate a bad word? It’s because it can cause people being pushed into not completing the tasks or not doing the things that have the highest priority. It causes confusion.

And if you consider a project where Case 1 and Case 2 are common, what happens? It causes some stuff to be bug infested which probably causes later delays and you’re never able to make up the time since when the developers are faster than the estimate, instead of moving on to the next item, they fill up the time with other stuff. Observe that I don’t assume that they are surfing the web or just idling, perhaps they refactor or something else. So, it is often good stuff, but not the most important stuff. And it does not help in catching up. So, what does this lead to; Case 3. If the project delivers poor quality and unfinished work and never makes up the time, of course the project will be delayed.

So, what word is better? Planned? Don’t think so, even if Microsoft Project use that word. This word most definitely leads to all these cases. Assumption is no better. When you think about it, you just have to realize that the word will lead to misunderstandings. So, what do you do?

Well, to handle Case 1 & 2 you need leadership and here I think that Kanban is a real savior. You cannot just drop the work and you cannot use the estimate as “your time”.

But what about that project manager? When it comes to the project manager’s need for planning, it’s important for him to realize that an estimate is a guess. A good or a bad guess. And when you’re guessing, you need to know the value of the guess. I like working the PERT analysis when this is a big issue (isn’t always??). You give three estimates; an optimistic, a probably and a pessimistic. Here is an excellent presentation on PERT analysis by Ricardo Vargas.

Pert Analysis in Projects

View more documents from Ricardo Vargas.

You can also add a value of risk to the estimate. So, when you estimate something, you estimate the size and the risk. And you would be stupid if you don’t realize that if you have a big task with a high risk, you cannot take that estimate for granted.

About kanban and estimations – just a clarification

I previously wrote a post about how we’re starting to implement kanban and I think there is room for some clarification about how we use our estimates.

What you need to keep in mind is that on top of our software development process, we have our project management process. This process raises the funds and priority for the project. When we implement a project, this affects the budget for different departments, based on the assumption that we save time or increase income. To give you a very basic principle, we can have a project which consists of two themes. So, we build a business case:

	Benefit department A	Benefit department B	Sum
Theme 1	500	100	600
Theme 2	100	300	400
	600	400	1000

 

In our business case, we should have a budget of at most 1000 to be able to break even. So, for simplicity sake only, lets say that we include resources matching 1000. The budget for department A & B will now be affected so A carries 60% of the costs and B 40%.

We start with Theme 1, since this has the highest priority. But we must not forget that we cannot continue with theme 1 during the whole project. If we would only deliver theme 1, department B would probably be disappointed. They got to carry 40% of a project which does not benefit them as much.

So, what I do with the estimates is just delivering this to the developers. They are made to understand about how much time will be spent on the different themes. But it’s important to stress that this does not affect the quality they will deliver. It just give them an idea on how big big part of their time should be spent on the different themes. This to enable them to deliver with quality. I see this as transparency in information between customers and developers.

This does not mean that the developers commit to an estimate and here I see the big difference with scrum. You cannot commit to deliver on an estimate. In most cases, things tend to take a little bit longer than expected. In some cases it takes shorter time. The important thing is that the team spend the right time on the right stuff to deliver the right quality.

So, how do I use the estimates? Well, I just keep the guys informed on how much of the budget on each theme that is spent and when we get near the end of the budget of theme 1, it becomes really important to finish the important things on that theme so that we don’t stand there and are faced with the options of delivering 1 with poor quality or 2 with too little effort.

In practice this means that when we’ve used 30% of our resources, I start to really stress completing the tasks, verifying with customers that they have the features they really need so that we can use the rest of the time just completing the work. By now, the guys think they are about 90% done, but means that half the work remains so now we should really avoid new features.