How good are your estimates
-
Have you ever given any estimations to your project lead/client/customers? If yes how far off were they. If you are able to give accurate estimates, how do you manage that. There general tendency I have found in programmers is to think that a particular thing is easy and it might take less time. But I have found that getting stuck in things that look simple does more to throw you off estimates than complex things.
-
Have you ever given any estimations to your project lead/client/customers? If yes how far off were they. If you are able to give accurate estimates, how do you manage that. There general tendency I have found in programmers is to think that a particular thing is easy and it might take less time. But I have found that getting stuck in things that look simple does more to throw you off estimates than complex things.
My last estimate was 85% over allowing 15% breathing room for new features. Basically, I take my official estimate, double it, and then double the result and I have a real estimate that is usually very accurate. Also, if you break down the project into very small finite tasks it is easy to get a really good estimate and metric for progress allowing time sinks to be moved to later in the process or flat out dumped.
Need custom software developed? I do C# development and consulting all over the United States. A man said to the universe: "Sir I exist!" "However," replied the universe, "The fact has not created in me A sense of obligation." --Stephen Crane
-
Have you ever given any estimations to your project lead/client/customers? If yes how far off were they. If you are able to give accurate estimates, how do you manage that. There general tendency I have found in programmers is to think that a particular thing is easy and it might take less time. But I have found that getting stuck in things that look simple does more to throw you off estimates than complex things.
It's *easy* 0. What's the best possible time frame? 1. Someone's going to boob - double it. 2. If marketing will be involved then double it again. 3. You going client driven? Then double it again. The joke is this is a pretty acurate method of estimation; assuming you have good grasp for #0.
Panic, Chaos, Destruction. My work here is done.
-
My last estimate was 85% over allowing 15% breathing room for new features. Basically, I take my official estimate, double it, and then double the result and I have a real estimate that is usually very accurate. Also, if you break down the project into very small finite tasks it is easy to get a really good estimate and metric for progress allowing time sinks to be moved to later in the process or flat out dumped.
Need custom software developed? I do C# development and consulting all over the United States. A man said to the universe: "Sir I exist!" "However," replied the universe, "The fact has not created in me A sense of obligation." --Stephen Crane
Ennis Ray Lynch, Jr. wrote:
I take my official estimate
How do you get that in the first place?
Ennis Ray Lynch, Jr. wrote:
Also, if you break down the project into very small finite tasks it is easy to get a really good estimate and metric for progress allowing time sinks to be moved to later in the process or flat out dumped.
I agree.
-
Ennis Ray Lynch, Jr. wrote:
I take my official estimate
How do you get that in the first place?
Ennis Ray Lynch, Jr. wrote:
Also, if you break down the project into very small finite tasks it is easy to get a really good estimate and metric for progress allowing time sinks to be moved to later in the process or flat out dumped.
I agree.
Rama Krishna Vavilala wrote:
How do you get that in the first place?
Experience
Need custom software developed? I do C# development and consulting all over the United States. A man said to the universe: "Sir I exist!" "However," replied the universe, "The fact has not created in me A sense of obligation." --Stephen Crane
-
It's *easy* 0. What's the best possible time frame? 1. Someone's going to boob - double it. 2. If marketing will be involved then double it again. 3. You going client driven? Then double it again. The joke is this is a pretty acurate method of estimation; assuming you have good grasp for #0.
Panic, Chaos, Destruction. My work here is done.
williamnw wrote:
assuming you have good grasp for #0.
Given the kind of issues that people post about on the C#, VB.Net, and ASP.Net forums, I think the phrase: "Houston, I think we have a problem" might be appropriate! :)
¡El diablo está en mis pantalones! ¡Mire, mire! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Personal 3D projects Just Say No to Web 2 Point Oh
-
williamnw wrote:
assuming you have good grasp for #0.
Given the kind of issues that people post about on the C#, VB.Net, and ASP.Net forums, I think the phrase: "Houston, I think we have a problem" might be appropriate! :)
¡El diablo está en mis pantalones! ¡Mire, mire! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Personal 3D projects Just Say No to Web 2 Point Oh
Abso-bloomin-lutly. This is were the undefinable that Junior alludes to above comes in - experience.
Panic, Chaos, Destruction. My work here is done.
-
Have you ever given any estimations to your project lead/client/customers? If yes how far off were they. If you are able to give accurate estimates, how do you manage that. There general tendency I have found in programmers is to think that a particular thing is easy and it might take less time. But I have found that getting stuck in things that look simple does more to throw you off estimates than complex things.
Hi Rama, There is a book about this topic from Microsoft called Software Estimation , Demystifying the Black art ISBN-13: 978-0 7356-0525-0 , written by Steve McConnell [http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351](<a href=)[^]">
With friendly greetings,:) Eric Goedhart
-
Hi Rama, There is a book about this topic from Microsoft called Software Estimation , Demystifying the Black art ISBN-13: 978-0 7356-0525-0 , written by Steve McConnell [http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351](<a href=)[^]">
With friendly greetings,:) Eric Goedhart
So my question to you is have you read that book and how much did it improve your estimation skill? BTW I have read that book ;)
-
Have you ever given any estimations to your project lead/client/customers? If yes how far off were they. If you are able to give accurate estimates, how do you manage that. There general tendency I have found in programmers is to think that a particular thing is easy and it might take less time. But I have found that getting stuck in things that look simple does more to throw you off estimates than complex things.
Consistently bad. I create a list of high-level tasks, break them down into smaller tasks, and estimate the time needed for each based on past experience... The end sum is almost always half of the actual time needed once all is said and done... ...Of course, if i anticipate this discrepancy and double the final result, it'll still end up being wrong by about the same margin. It's like i work slower when i think i have more time...
-
So my question to you is have you read that book and how much did it improve your estimation skill? BTW I have read that book ;)
Hi Rama, I bought this book out of interest since I knew that some people needed to make an estimation about how long a software project would take, but never was aware that books about software estimation existed. There was no personal goal for me to buy it since I moreless know how much time the things I want will cost me to realise when I build websites. I partially read the book to get some idea about the topic since it's nice to have some knowledge, but no it didn't improve my estimation skills as far as I know.
With friendly greetings,:) Eric Goedhart
-
Have you ever given any estimations to your project lead/client/customers? If yes how far off were they. If you are able to give accurate estimates, how do you manage that. There general tendency I have found in programmers is to think that a particular thing is easy and it might take less time. But I have found that getting stuck in things that look simple does more to throw you off estimates than complex things.
I use the 'Scottie' principle of time estimation - figure out how long and double it. If you come in under then you're a hero; come in over and you're a zero. Oh, and 20+ years of experience also come in quite handy...
-
Consistently bad. I create a list of high-level tasks, break them down into smaller tasks, and estimate the time needed for each based on past experience... The end sum is almost always half of the actual time needed once all is said and done... ...Of course, if i anticipate this discrepancy and double the final result, it'll still end up being wrong by about the same margin. It's like i work slower when i think i have more time...
Shog9 wrote:
It's like i work slower when i think i have more time.
I think it is a problem with everyone.:)
-
Have you ever given any estimations to your project lead/client/customers? If yes how far off were they. If you are able to give accurate estimates, how do you manage that. There general tendency I have found in programmers is to think that a particular thing is easy and it might take less time. But I have found that getting stuck in things that look simple does more to throw you off estimates than complex things.
Yes. I've some off base estimates before, but have tempered my optimism in the face of bitter and hard learnt reality. As has been mentioned above you should break a task into small easy to define parts, estimate those, add cock up and discovery time then sum them together. It's always surprising how big that number is. Also, even given the above, any project of sufficient complexity will start to wander off course. It's best to have multiple re-evaluation points along the way.
10110011001111101010101000001000001101001010001010100000100000101000001000111100010110001011001011
-
Have you ever given any estimations to your project lead/client/customers? If yes how far off were they. If you are able to give accurate estimates, how do you manage that. There general tendency I have found in programmers is to think that a particular thing is easy and it might take less time. But I have found that getting stuck in things that look simple does more to throw you off estimates than complex things.
I've gotten very good at them because the only estimates I do are for cases in our fogbugz database where the new features and bugs are entered for our app. I find that my best estimates are the ones I give off the top of my head quickly after a quick read through of the case. The worst ones are when I stop and think about it for a long time and analyze it a lot. Proving once again that conscious thought is the main limiting factor in what our brains can accomplish.
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
-
I've gotten very good at them because the only estimates I do are for cases in our fogbugz database where the new features and bugs are entered for our app. I find that my best estimates are the ones I give off the top of my head quickly after a quick read through of the case. The worst ones are when I stop and think about it for a long time and analyze it a lot. Proving once again that conscious thought is the main limiting factor in what our brains can accomplish.
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
-
I use the 'Scottie' principle of time estimation - figure out how long and double it. If you come in under then you're a hero; come in over and you're a zero. Oh, and 20+ years of experience also come in quite handy...
-
Have you ever given any estimations to your project lead/client/customers? If yes how far off were they. If you are able to give accurate estimates, how do you manage that. There general tendency I have found in programmers is to think that a particular thing is easy and it might take less time. But I have found that getting stuck in things that look simple does more to throw you off estimates than complex things.
Before my career started my estimates were horribly optimistic. I learned from that and fairly soon after becoming a professional developer, got and maintained a reputation for having dead-on estimates. The more experience I get, the better my estimates. One "trick" is to always be conscious of how long things take; not just projects, but individual tasks. When a new project comes up, you break it down and find comparable tasks. (This is all mental; I don't look at pieces of paper.) A twist on this is that many times my employer or client needs something done by a specific deadline. I then work in reverse and identify what can and can't be done in that time frame. I then give them choices. What's weird to me is how often management doesn't understand this or don't want to. (Incidentally, one thing that really helped was learning how to do script breakdowns in film school. Oddly enough, though, my programming experience got in the way on an educational film I did; I was too pessimistic. On the other hand, my crew, who were used to working 12 hours a day were working 8 to 9 and loved me--I think it paid off [we had one very long day and I confirmed once again that after 10 hours, productivity drops precipitously].)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
Consistently bad. I create a list of high-level tasks, break them down into smaller tasks, and estimate the time needed for each based on past experience... The end sum is almost always half of the actual time needed once all is said and done... ...Of course, if i anticipate this discrepancy and double the final result, it'll still end up being wrong by about the same margin. It's like i work slower when i think i have more time...
Shog9 wrote:
...Of course, if i anticipate this discrepancy and double the final result, it'll still end up being wrong by about the same margin. It's like i work slower when i think i have more time...
In my current task, which should not take more than a week ( true estimation ), I worked for 3.5 days and got about 95% done. Then the boss mentioned when he needs it (which was in 3 weeks), and it took me 2 weeks to complete the rest 5%, which should not have taken more than a day. Of course, I'd multiple other things going, but the thing is, in my mind I said I have enough time and ended up pushing it to the backburner. :-O :-\
Yusuf May I help you?
-
Shog9 wrote:
It's like i work slower when i think i have more time.
I think it is a problem with everyone.:)
Rama Krishna Vavilala wrote:
I think it is a problem with everyone
ditto!:thumbsup:
Yusuf May I help you?