How good are your estimates
-
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 ;)
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
-
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.
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.
-
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?
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?
-
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.
Underestimating is very common. I find I double my gut estimates and get pretty close. The fact is, it's impossible to know how long something will take, unless you've done it all before, and even then, only if you can constrain the client from asking for changes, etc. I mean, the simplest thing can suddenly be hard, and vice versa.
Christian Graus Driven to the arms of OSX by Vista. Please read this[^] if you don't like the answer I gave to your question.
-
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.
Excellent. My estimates are usually pretty good. I always quote teh customer more than my estimate (to give some breathing room in case of unforseen incidents) All those that say they estimate and double it - why not just estimate higher in thr first place? Huh? Experience allows me to be as accurate as I am. If I am unsure about something (say some requirement I haven't used before - say drag and drop on a web page - I will do a little initial R&D first - and build in extra time for that. For very short tasks my rule of thumb is that NOTHING takes less than 1/2 day. Change the text on a button - 1/2 day. I don't deal in hours, just days, and generally estimate each minor task in whole day amounts. Again, experience counts more than anything. Oh - and knowing what you are estiomating! I've seen people (many times) be asked to estimate for a job which is so ill defined that iut coujld be anything from a one week to 6 month project. In those circumstances I refuse to be drawn into an estimate without documenting what is being estimated on - otherwise you start estimating a week, but the customer is imagining all of these extra features that you hadn't a clue about and they're always unhappy about it when you increase the estimate becasue in their head they KNEW what they wanted - they just hadn't told anyone. Finally (I do ramble, don't I) I try to double-check with others. So if I estimate a task at, say, one week, and am going to assign it to a particular developer, I will give them the task and ask them to estimate it. You're right that very often they will estimate a couple of days. I then heve the choice (depending on the person and their history) of telling them my estimate was higher, and to do their best to beat it, or telling them that they NEED to do it in two days - while keeping my original one week estimate in the project plan. If they finish in 2 days, pat on back, beers all round. If not, no efect on the project, and I can show them how to estimate more accurately next time by learning from their mistakes.
___________________________________________ .\\axxx (That's an 'M')
-
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 problem is that I (and other devs on my team) keep getting thwarted by folks that persist on wanting to know the absolute most optimistic outcome. "What if that problem didn't exist? How long would it take?". If the figures are presented in terms of we expect X, but it could be as little as Y, or as much as Z then the client services team gets itself in to a mess wondering what to tell the client. How about the truth? It isn't a fixed sum game. If I knew then what I know now I'd give you a different number - That's why it is presented as a range, so that unknowns are (to an extent) accounted for.
Rama Krishna Vavilala wrote:
There general tendency I have found in programmers is to think that a particular thing is easy and it might take less time.
I think there is a built in optimism amongs most developers, myself included. Also, developers also like to please folks and if pressed the estimates they give will tend towards unrealistic optimistic answers. In reality that strategy is just deferring the conflict until later. It then becomes more painful towards the end of the project when the deadlines that were set based on the estimates whoosh by.
Man who stand on hill with mouth open wait long time for roast duck to drop in
-
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.