About Estimating
One of the most difficult tasks in software development is estimating also known as guessing. Here are a couple of thoughts about the topic.
- Estimates aren’t Commitments. At least they shouldn’t. Lets assume you estimate you need 1 hour from your home to the airport, through all formalities and into the plane. Do you leave your house 1 hour before departure of the plane? Probably not. You’ll add all kinds of buffers and leave your house a lot earlier. Same should apply to any kind of project. If you think it takes 6 months it is a bad idea to promise a delivery date in 6 months. Promise 7, 9 or 12 months, depending how bad it is when you show up late.
- Estimates aren’t measurments. If you want to build a shelf, you can measure the space you have available, and if you measure properly you can cut the boards according to that measurement and they will fit. If they don’t it is probably your fault because you didn’t measure properly. With the tools in your house you might be able to measure size up to a couple meters with an error of about 1/1000 and if you want to measure more precise you just have to invest in better tools and measure more carefully.Not so with software. If you estimate a task to take a day you might be done after a day. Or maybe after 6 hours. Or you give up after 3 days. There is no way to be sure. You can’t just put more effort in estimating to make it more precise. Tools won’t help you much. The only thing reducing the margin of error is actually implementing it.
- Some basics in statistics. If you roll a dice once you will score approximately 3.5 points. With a margin of error of about 100%. If you roll the dice 1 million times the average value will be 3.5 with pretty good precision. This is no accident, but pretty strong math. The basic idea is that you can add up indipendent random events and that the relative uncertainty is smaller for the added up events than for each single event. This is good news since if you estimate a project you typically break it down into tasks and estimate each task. Then you add up everything and get your result. Which has a smaller range of error.
- The rule above applies does not apply. It holds only when the events (guesses/estimates) follow a normal distribution and are independent of each other. Neither is true for software estimates. Go figure.
- We learn through feedback
It’s almost impossible to learn anything without getting feedback on how you are doing. Imagine learning chess without anybody ever telling you when you make a bad or even illegal move. You just have a book with the rules and play games against yourself. How likely do you think it is to ever become a respectable chess player? Nil? I think so too. But with estimating we are often in such a situation. When you do waterfall projects you often do estimates for 100s of tasks in one go and only a year later you get the feedback: The sum of your estimates was 20% of. It’s really hard to learn this way. The situation improves a lot when you follow agile practices, where you typically estimate smaller batches, closer to the time when they are actually performed. This enables you to actually learn how long tasks take.
Hi,
estimating was the content of my last week podcast. Maybe it is interesting. Check out ZA003: In die Glaskugel schauen – Sinnvolle Releasestrategien & Aufwände schätzen
Maik
I had some trouble initially agreeing with point 1, I think I get what you mean: estimates != product ready for use. Please correct me if this is wrong.
Engineers should be able to commit to deliver whatever they have agreed to in the time frame they have agreed to. However it is usual that the definition of done is different for engineers/management/customers.
If the management does not have a grip on the software process or realities then you may need to factor in time for “done done” yourself.
@Andy What I’m trying to say is a little different.
What people estimate is basically a median, i.e. if you have good estimators you can expect in one half of the cases to finish before the estimated time and one half after the estimated time.
This is not something you base a promise or commitment on. For a commitment you want something like a 80, 90 or 9x percentile. This is not what you get when you ask for an estimate.
I’m sure it is possible to achieve more than a 50% chance of being on the right side of an estimate. I have managed this myself in the last few months through my own learning and retrospection.
If we cannot commit to that then no software projects will ever commence.
Maybe there is a case for a new kind of contract where very pessimistic estimates will be given for everything but the customer will share in the profits if the software comes in early.
If that was to work then the software company would need to be very open to customers about hours spent and probably on history of other projects too. This would be a good thing for both parties I think.
Of course you can get more the 50% confidence. But that is not the estimate. If you ask someone to ESTIMATE you will get a median of the actual effort needed.
If you turn around, multiply with your hourly rate and make that the price & release date (i.e. you make them promises/commitment) you ask for trouble.
I’ll try an example: My son might call me at work and as me when I will come home. I’ll think for a moment about the stuff I have to do today and give an estimate: Probably at 5pm. (That is an honest estimate).
He’ll do what managers tend to do: “Oh great so you can take me to chess training. We’ll have to leave at 5pm”
And I will stop him: While I might be home at 5 pm an it is actually a good estimate, I can’t promise it. I might be able to promise 5:30 or 6pm.
Its ok for a 7year old to make the mistake, but not for a manager. Managers don’t have dads hanging around stopping them from making such stupid mistakes.
@Andy your point about the contract is actually very valid. The whole way most contracts get arranged is basically tuned for screwing each other. I think I’write an article about that topic ..
Thanks for the more in depth description. I see this from managers who would prefer, in effect to put the whole responsibility of the project on the heads of the software writers instead of planning for actual success.
Good talking with you!