How good are your estimates
-
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...
digital man wrote:
I use the 'Scottie' principle of time estimation - figure out how long and double it
Incorrect. Kirk: Scotty, how soon can you get the ship ready? Scotty: 8 weeks, sir! But since we don't have 8 weeks, I'll get it done in 2. Kirk: Scotty, do you always multiply your estimates by a factor of 4? Scotty: Aye, Sir! How else could I keep my reputation as a miracle worker?
Man who stand on hill with mouth open wait long time for roast duck to drop in
-
Words of Marc Clifton.
Cheers, Vikram.
Current activities: Films: Philadelphia TV series: Friends, season 4 Books: Six Thinking Hats, by Edward de Bono.
Carpe Diem.
Where n is PI... Hmmmmm Pie!
Man who stand on hill with mouth open wait long time for roast duck to drop in
-
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:
I create a list of high-level tasks
That tends to be my problem to start with - client cannot define the result they expect. I'm currently in a build it and see what we get then we'll have another go. However I am NOT on a fixed price and some of the requests are doozies.
Never underestimate the power of human stupidity RAH
-
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.
Awful; too many times my projects took six months longer than I had estimated. So now I just say that... e.g. "It should take me two weeks, but it could take six months longer than that."
-
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.
Pretty good but then I give best and worst scenario and how certain I'm on them, eg. "A will take 3 days with 75% and 6 days with 25%". This show that I'm pretty certain but there are some question marks. If I instead had said "3 days, 95% and 4 days 5%" I would be very surprised if it took more than 3 days. In the same way I can say that I'm not very comfortable with a task "3 days at 25%, 6 days at 75%". It might go easy but there could also be a major problem... When the full project is completed, I'll go through all my estimates and tries to deduce why the correct ones were correct and the others not... During a project and I happened to make a grave misjudgment I'll adjust all my other estimates of the same category, eg. not all of them. I't could be that I totally screwed up and thought library so and so was much easier than it turned out to be but that shouldn't influence my estimates for some other library (unless from the same source...) /Jonas ps. When I don't have a clue, I'll make some WAG and multiply with the optimistic coefficient PI... ps2. Don't forget to add time for transition between project and non-productive time (such as lunch, sleep etc) when summarizing.
-
Shog9 wrote:
It's like i work slower when i think i have more time.
I think it is a problem with everyone.:)
In my opinion it doesnt count as a problem. When programmer knows there is alot of time, work "speed" might appear slower than when in pressure. But that shouldnt be abused that way, under pressure is a state that doesnt last very long. Maybe few years max? Make too tight estimates and too close deadlines and your programmers work faster just to find them become dull and unspirited in the end, for working years very hard and accomplish actually nothing more that could have been accomplished with normal phase. Cheated them, Ha!
-
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 estimates are usually pretty close to the mark, but can also end up being wildy inaccurate. Of course the previous sentence is just an estimate :)
The only thing unpredictable about me is just how predictable I'm going to be.
-
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.
-[The *DAVE* factor!]- Whenever I start a job I tell my new manager: I have a major weakness, but I can also tell you exactly how to compensate for that weakness so that everyone is happy. When I make an estimate, take whatever I say and multiply it by three. And then - and this is the important part - don't tell me that you've done it! Amazingly, most managers cannot do this. Sometimes they'll add 50%, and sometimes they'll double it. Rarely, they'll triple it as advised, ... but whatever factor they use, they insist on telling me that they've done it. Of course, those managers are thinking that, amazingly, I'm incapable of multiplying by three myself. But, you know what? I've tried that, and I can tell you it doesn't work.
-
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.
A co-worker (also a developer) and I once demonstrated to our manager the problem with estimation. We showed him a screen in which he needed to input basic customer information - name, address, phone, etc. We asked him how long it would take him to fill out the form and submit the data. He gave an optimistic 5 minutes. We knew, however, that even though this form was in production in a major application for our company, there was a bug that would completely prevent him from completing the task at all. The bug was of the frustrating nature that it really didn't tell you what the problem was, so you kept trying different methods of getting around it. After 15 minutes we informed the manager that he had now blown the budget by 300%. He continued to try for who knows how long, but we got our point across.
You are here - through no fault of mine!
-
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 old adage of once you come up with an estimate then "double value and up the units by 1" so if I estimate 2 days, I say 4 weeks. I'm fairly accurate and I'm never late (unless there's outside influence like last minute requirements changes, bosses putting me on a quick 1 day project that lasts the 2 weeks I'm suppose to be working on the other project, etc).
Joe V My Blog on Testing Me, Myself, and I SGP Robotics team and FIRST Robotics
-
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
-
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.
There is no such thing as an accurate estimate... That is why they are called estimates. Only managers insist on taking estimates as actual target dates and everything goes down hill from there. That is why there is still so much project failure in IT these days. I would recommend reading Stephen McConnel's excellent "Rapid Application Development" to understand how software engineers create dynamic estimates which becomeincreasingly more accurate as the project progresses. As a software engineer I have used this technique and demonstrated the accuracy of the concepts involved. My supervisor was still not impressed and still refused to consider my techniques even when a m ajor project of his was starting to fall behind schedule due to his own inaccurate way of developing project schedules.
Steve Naidamast Black Falcon Software, Inc. blackfalconsoftware@ix.netcom.com
-
Yusuf wrote:
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.
Did you bill the customer for the 13.5 days? It sounds like you did other things and it took you 2 weeks to do 1 days work. Or did it actually take you 80 hours to do 1 days work?
Joe Simes wrote:
Did you bill the customer for the 13.5 days?
No, my employer is my customer. I had other tasks which I have finished while procrastination for that task which takes one day to finish :-O
Yusuf May I help you?
-
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.
Rama, If you give me your email address (Mine = cyberhacker@pobox.com) I will send you an excel sheet, (2007) that I use for estimation. IMHO -its very well done. I'm sure you can edit this, and get the hang of it, make it your own. >> Let me know if you need it saved as Office 2003 Format! Michael Kelly .NET Software Developer Duke Energy\Apps Enterprise\Corporate Applications - Non Sourced office: 704.382.6430 Please consider the environment before printing this e-mail
Where there's smoke, there's a Blue Screen of death.
-
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.
The trick is to meet with and interview the potential client and let them tell you what it is they they think they want. Be thorough, cover every aspect that the application/task could possibly touch upon. That gives you an idea of what they are trying to do. After you understand that, YOU then proceed to tell them what it is that they really want based on what you know can be done. Base your estimate on that knowlege.
-
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.
Usually I am asked to give an estimate when what is to be done is unspecified. So I can declare I am done when the time is up. I give it my best shot and then multiply by either "pi" or "e", not sure which is best but I know some natural law must be involved.
-
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.
For me, I find I must break things down into 1-3 day chuncks. If I don't, my estimate is wildly inaccurate. However, when I do, I uncover tons more work than was previously thought was there, and my estimates tend to be huge. The real question however, is whether anyone acutually wants accurate time estimates? Is it more acceptable in your organization to underestimate and slip delivery, or to more accurately estimate the longer duration actually required?
patbob
-
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
My best estimates are from the knowns. As in, I've done that before. Broken down as tightly as possible into specific units. This much for a basic report, this for a view/query write, this for data normalization, etc. I've done stats on my projects, so it is part experience and part data. The killer, for me, is the unknowns. The more I can identify the unknowns as unknowns the more likely I am to be able to tell how good the estimate is. They tend to either make no impact or expand the job to a much larger size. The latter being the one I mostly care about. But that doesn't make the estimate better, I just know to mistrust it more. To get the estimate closer at that point I then try to figure out what I don't know about the size of the unknown. If I still don't know I get very hedgey on the value of the estimate when talking to the customer/manager. Meetings are the other issue. If I go to a two hour meeting once a week then I'm going to have a minimum of an additional two hours to deal with the results of that meeting. Often more. More meetings = more changes and alterations. If it is a small number of meetings then the estimate can be more associated with the planned work.
_____________________________ Those who study history are doomed to watch others repeat it. -Scott M.
-
For me, I find I must break things down into 1-3 day chuncks. If I don't, my estimate is wildly inaccurate. However, when I do, I uncover tons more work than was previously thought was there, and my estimates tend to be huge. The real question however, is whether anyone acutually wants accurate time estimates? Is it more acceptable in your organization to underestimate and slip delivery, or to more accurately estimate the longer duration actually required?
patbob
Dead on with the real question. And, is it better for you to land the job with an inaccurate estimate and then make apologies later, or is it better to risk not getting the job and giving it to someone who prefers to give inaccurate estimates. Vicious situation.
_____________________________ Those who study history are doomed to watch others repeat it. -Scott M.
-
Rama Krishna Vavilala wrote:
have you read that book
Yes
Rama Krishna Vavilala wrote:
how much did it improve your estimation skill?
Quite a lot. I try out the techniques on my personal projects, and I've gotten visibly better. Haven't applied them on official work though, mostly because estimates are a joke - deadlines are usually fixed before we are asked for estimates :(
Regards Senthil [MVP - Visual C#] _____________________________ My Home Page |My Blog | My Articles | My Flickr | WinMacro