Time Estimates
-
I've just been emailed a Change Request, and asked to give an estimate of how long it will take me to implement. I have replied that it will take 15 seconds. When they first discussed the problem some months ago I worked on a few solutions to get my head around the problem as much as anything else. They have requested the way I suggested, and so all the code work is already done and I just have to upload one file and restart the service.
Every man can tell how many goats or sheep he possesses, but not how many friends. Shed Petition[^]
-
What part of the following do you not understand: 1: Estimate 8 hours. 2: Do it in 15 seconds. 3: Spend the rest of the day on the CP Doom server. My team could use a bit of help. I think the Canadians cheat.
-
I've just been emailed a Change Request, and asked to give an estimate of how long it will take me to implement. I have replied that it will take 15 seconds. When they first discussed the problem some months ago I worked on a few solutions to get my head around the problem as much as anything else. They have requested the way I suggested, and so all the code work is already done and I just have to upload one file and restart the service.
Every man can tell how many goats or sheep he possesses, but not how many friends. Shed Petition[^]
We use Agile from the start... estimate in points. We can draw a time estimation from looking at what our average point burndown is per sprint. Say I burn an average of 20 points per sprint (2 weeks in our case). The task that was given I estimate to be 10 points, thus should take 1 week to finish.
"Program testing can be used to show the presence of bugs, but never to show their absence." << please vote!! >>
-
I've just been emailed a Change Request, and asked to give an estimate of how long it will take me to implement. I have replied that it will take 15 seconds. When they first discussed the problem some months ago I worked on a few solutions to get my head around the problem as much as anything else. They have requested the way I suggested, and so all the code work is already done and I just have to upload one file and restart the service.
Every man can tell how many goats or sheep he possesses, but not how many friends. Shed Petition[^]
A very very dangerous answer. If all goes well, will take 10 seconds indeed. But if any bug pops up (possibly because the system changed since) fixing will be a four hours task that you'll have to spend on your leisure time.
-
Aargh! The network will go down! The server will crash! Your Windows license will corrupt, black-screening you! SOMETHING will happen to make you look an idiot!
I wanna be a eunuchs developer! Pass me a bread knife!
-
I've just been emailed a Change Request, and asked to give an estimate of how long it will take me to implement. I have replied that it will take 15 seconds. When they first discussed the problem some months ago I worked on a few solutions to get my head around the problem as much as anything else. They have requested the way I suggested, and so all the code work is already done and I just have to upload one file and restart the service.
Every man can tell how many goats or sheep he possesses, but not how many friends. Shed Petition[^]
Now youve done it, the next time they want something doing they will look at this and say "oh it took 15 seconds to that one and this ones is easier, so he should be able to do it in 10" - handing you 15 hours of work
You cant outrun the world, but there is no harm in getting a head start Real stupidity beats artificial intelligence every time.
-
I've just been emailed a Change Request, and asked to give an estimate of how long it will take me to implement. I have replied that it will take 15 seconds. When they first discussed the problem some months ago I worked on a few solutions to get my head around the problem as much as anything else. They have requested the way I suggested, and so all the code work is already done and I just have to upload one file and restart the service.
Every man can tell how many goats or sheep he possesses, but not how many friends. Shed Petition[^]
-
What part of the following do you not understand: 1: Estimate 8 hours. 2: Do it in 15 seconds. 3: Spend the rest of the day on the CP Doom server. My team could use a bit of help. I think the Canadians cheat.
Every self-respecting nerd should remember the words of Scotty (back from the dead) in the dyson sphere episode: Lt. Commander Geordi La Forge: Yeah, well, I told the Captain I'd have this analysis done in an hour. Scotty: How long will it really take? Lt. Commander Geordi La Forge: An hour! Scotty: Oh, you didn't tell him how long it would *really* take, did ya? Lt. Commander Geordi La Forge: Well, of course I did. Scotty: Oh, laddie. You've got a lot to learn if you want people to think of you as a miracle worker.
-
I've just been emailed a Change Request, and asked to give an estimate of how long it will take me to implement. I have replied that it will take 15 seconds. When they first discussed the problem some months ago I worked on a few solutions to get my head around the problem as much as anything else. They have requested the way I suggested, and so all the code work is already done and I just have to upload one file and restart the service.
Every man can tell how many goats or sheep he possesses, but not how many friends. Shed Petition[^]
I used to structure my code so some of it was driven by a database. Many times the change took less time than it took for the principles to decide what they wanted done. I was telecommuting and at the end of the phone conference they'd ask how long would it take to implement and I'd say, "It's already done." In retrospect, I did not do myself any favors. I should have said "A week" and then announce later it was done ahead of schedule. Since the task did not get on any schedule, there was no record of my performance. Nothing I could point to anyway.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
-
I've just been emailed a Change Request, and asked to give an estimate of how long it will take me to implement. I have replied that it will take 15 seconds. When they first discussed the problem some months ago I worked on a few solutions to get my head around the problem as much as anything else. They have requested the way I suggested, and so all the code work is already done and I just have to upload one file and restart the service.
Every man can tell how many goats or sheep he possesses, but not how many friends. Shed Petition[^]
One of my physics professors said that he would always ask for a grant to do what he had already done, then spend the time and grant money doing his next project, sending them the results of the first project when the second one is done.
-
I've just been emailed a Change Request, and asked to give an estimate of how long it will take me to implement. I have replied that it will take 15 seconds. When they first discussed the problem some months ago I worked on a few solutions to get my head around the problem as much as anything else. They have requested the way I suggested, and so all the code work is already done and I just have to upload one file and restart the service.
Every man can tell how many goats or sheep he possesses, but not how many friends. Shed Petition[^]
so you have no plans to - unit test your change or - regression test the system? I hope your system is teeny.
-
I've just been emailed a Change Request, and asked to give an estimate of how long it will take me to implement. I have replied that it will take 15 seconds. When they first discussed the problem some months ago I worked on a few solutions to get my head around the problem as much as anything else. They have requested the way I suggested, and so all the code work is already done and I just have to upload one file and restart the service.
Every man can tell how many goats or sheep he possesses, but not how many friends. Shed Petition[^]
It will take you more than 15 seconds to sit down at your desk, log on, and open your code browser. This post is an unintentional summary of how people mis-estimate. Certainly executing the checkin command on that code will only take 15 seconds, but you forgot the several steps you have to do before and after that. You probably also forgot that your code base evolved over the past few months, and you may have to resolve conflicts. Maybe you didn't write really good test cases because you were just noodling, and now you need to do them. Maybe you didn't check your return codes, because you were just trying something out, and you need to fix that. Maybe there's just a bit of documentation work... I think it's bad practice to give your boss an estimate immediately unless you prepared in advance. Say, "That code is mostly written. Let me check a few things and email you." Then you can have a quick look at that code and be sure it's really production-ready. Yhe result will be an estimate you can meet, and a happy boss. In my humble opinion, no task can be estimated to take less than one person-day, because we aren't actually very good at predicting how many words per minute we type, or what casual conversation will get our attention. You'll get the task done in less than a day. That's ok. Your boss won't notice or remember if you're done ahead of schedule. But he'll notice if you're late. I agree with the poster who said you need to include all the time you spent those months ago in the estimate. Then you also say "The work is 90% done, because I worked unpaid overtime figuring it all out. Wasn't I smart." If you're not getting paid for overtime, the least you can do is get some street credit for it.
-
I used to structure my code so some of it was driven by a database. Many times the change took less time than it took for the principles to decide what they wanted done. I was telecommuting and at the end of the phone conference they'd ask how long would it take to implement and I'd say, "It's already done." In retrospect, I did not do myself any favors. I should have said "A week" and then announce later it was done ahead of schedule. Since the task did not get on any schedule, there was no record of my performance. Nothing I could point to anyway.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
When something is "Already done", i say it will take at least an hour, so if something is not as expected i will be able to change it and have it "on time". :)
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
It will take you more than 15 seconds to sit down at your desk, log on, and open your code browser. This post is an unintentional summary of how people mis-estimate. Certainly executing the checkin command on that code will only take 15 seconds, but you forgot the several steps you have to do before and after that. You probably also forgot that your code base evolved over the past few months, and you may have to resolve conflicts. Maybe you didn't write really good test cases because you were just noodling, and now you need to do them. Maybe you didn't check your return codes, because you were just trying something out, and you need to fix that. Maybe there's just a bit of documentation work... I think it's bad practice to give your boss an estimate immediately unless you prepared in advance. Say, "That code is mostly written. Let me check a few things and email you." Then you can have a quick look at that code and be sure it's really production-ready. Yhe result will be an estimate you can meet, and a happy boss. In my humble opinion, no task can be estimated to take less than one person-day, because we aren't actually very good at predicting how many words per minute we type, or what casual conversation will get our attention. You'll get the task done in less than a day. That's ok. Your boss won't notice or remember if you're done ahead of schedule. But he'll notice if you're late. I agree with the poster who said you need to include all the time you spent those months ago in the estimate. Then you also say "The work is 90% done, because I worked unpaid overtime figuring it all out. Wasn't I smart." If you're not getting paid for overtime, the least you can do is get some street credit for it.
For me, nothing takes less than a day, this way i can finish everything in less time and look like a hero. :-D
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
Every self-respecting nerd should remember the words of Scotty (back from the dead) in the dyson sphere episode: Lt. Commander Geordi La Forge: Yeah, well, I told the Captain I'd have this analysis done in an hour. Scotty: How long will it really take? Lt. Commander Geordi La Forge: An hour! Scotty: Oh, you didn't tell him how long it would *really* take, did ya? Lt. Commander Geordi La Forge: Well, of course I did. Scotty: Oh, laddie. You've got a lot to learn if you want people to think of you as a miracle worker.
I live by this motto, I always double my estimated time. and if I do get into a bind at least I got the extra time to use to figue it out. :laugh: p.s. never tell your manager you do this, they will cut the time in half or more!
-
It will take you more than 15 seconds to sit down at your desk, log on, and open your code browser. This post is an unintentional summary of how people mis-estimate. Certainly executing the checkin command on that code will only take 15 seconds, but you forgot the several steps you have to do before and after that. You probably also forgot that your code base evolved over the past few months, and you may have to resolve conflicts. Maybe you didn't write really good test cases because you were just noodling, and now you need to do them. Maybe you didn't check your return codes, because you were just trying something out, and you need to fix that. Maybe there's just a bit of documentation work... I think it's bad practice to give your boss an estimate immediately unless you prepared in advance. Say, "That code is mostly written. Let me check a few things and email you." Then you can have a quick look at that code and be sure it's really production-ready. Yhe result will be an estimate you can meet, and a happy boss. In my humble opinion, no task can be estimated to take less than one person-day, because we aren't actually very good at predicting how many words per minute we type, or what casual conversation will get our attention. You'll get the task done in less than a day. That's ok. Your boss won't notice or remember if you're done ahead of schedule. But he'll notice if you're late. I agree with the poster who said you need to include all the time you spent those months ago in the estimate. Then you also say "The work is 90% done, because I worked unpaid overtime figuring it all out. Wasn't I smart." If you're not getting paid for overtime, the least you can do is get some street credit for it.
A very wise man and the best PM I've ever had once taught me we you mention above. - No task is actually less than a day, because there is time required for many other tasks that go with it - Adding tasks to a sprint, even if at first it does not look like it will affect the timeline, it usually does. It is a great dilemma, because at first you think you are doing your customer good by adding new tasks but in reality what happens is that as I say "no good deed goes unpunished", because you add new stuff, overload the work required to be done by the team, and there is a possibility that quality may not be as expected. So look at the dilemma: - You say can't be done and the customer thinks you are not serving them properly and they are not happy. - You say yes, and do it and there is a chance that you will not deliver the expected quality and the customer will definitively not be happy. So what do you do?
My new toy: www.cloudclipx.com -- If I have 8 hours to chop down a tree, I spend 6 sharpening my ax!
-
A very wise man and the best PM I've ever had once taught me we you mention above. - No task is actually less than a day, because there is time required for many other tasks that go with it - Adding tasks to a sprint, even if at first it does not look like it will affect the timeline, it usually does. It is a great dilemma, because at first you think you are doing your customer good by adding new tasks but in reality what happens is that as I say "no good deed goes unpunished", because you add new stuff, overload the work required to be done by the team, and there is a possibility that quality may not be as expected. So look at the dilemma: - You say can't be done and the customer thinks you are not serving them properly and they are not happy. - You say yes, and do it and there is a chance that you will not deliver the expected quality and the customer will definitively not be happy. So what do you do?
My new toy: www.cloudclipx.com -- If I have 8 hours to chop down a tree, I spend 6 sharpening my ax!
xavier morera wrote:
So look at the dilemma:
- You say can't be done and the customer thinks you are not serving them properly and they are not happy.
- You say yes, and do it and there is a chance that you will not deliver the expected quality and the customer will definitively not be happy.You serve your customer best by giving them the best information you have. You tell them what you think you can do, and what you think you cannot do. If the customer is unhappy, they have to live with it. You have to be philosophical about this situation. If the customer goes to another vendor who promises more than they can deliver, the customer will learn a lesson. They will be back to you because you spoke the truth, and your competitor did not. If your competitor delivers, then you learn a lesson about estimation, or about dev methodology, or about hiring good people.
-
xavier morera wrote:
So look at the dilemma:
- You say can't be done and the customer thinks you are not serving them properly and they are not happy.
- You say yes, and do it and there is a chance that you will not deliver the expected quality and the customer will definitively not be happy.You serve your customer best by giving them the best information you have. You tell them what you think you can do, and what you think you cannot do. If the customer is unhappy, they have to live with it. You have to be philosophical about this situation. If the customer goes to another vendor who promises more than they can deliver, the customer will learn a lesson. They will be back to you because you spoke the truth, and your competitor did not. If your competitor delivers, then you learn a lesson about estimation, or about dev methodology, or about hiring good people.
Yes. I agree 100%. In our case things changed little by little. There was a (crazy) PM that was replaced by someone that understands better this dilemma. Although it is always a possibility that new things get added. Also, losing a contract is not a good thing for me :)
My new toy: www.cloudclipx.com -- If I have 8 hours to chop down a tree, I spend 6 sharpening my ax!
-
I've just been emailed a Change Request, and asked to give an estimate of how long it will take me to implement. I have replied that it will take 15 seconds. When they first discussed the problem some months ago I worked on a few solutions to get my head around the problem as much as anything else. They have requested the way I suggested, and so all the code work is already done and I just have to upload one file and restart the service.
Every man can tell how many goats or sheep he possesses, but not how many friends. Shed Petition[^]
Tiny: "About 5 minutes" - Reality: 30s or less Very Small: "About 10 minutes" - Reality: 5m or less. Small: "About an hour" - Reality - 30 minutes or less Medium: "About 4 hours" - Reality - 2 hours or less Medium-Large: "About 8 hours" - Reality: 4 hours or less I think you can follow the pattern :)
-= Reelix =-
-
Yes. I agree 100%. In our case things changed little by little. There was a (crazy) PM that was replaced by someone that understands better this dilemma. Although it is always a possibility that new things get added. Also, losing a contract is not a good thing for me :)
My new toy: www.cloudclipx.com -- If I have 8 hours to chop down a tree, I spend 6 sharpening my ax!
xavier morera wrote:
losing a contract is not a good thing for me
Losing a contract may be better than being unable to complete the contract on time. If you have the kind of customers that never come back, then you might as well bid optimistically. Of course, if you bid optimistically and don't perform, you will have customers who never come back. Companies who work like this are bottom feeders. It's a niche in the business ecology. There will always be bottom feeders. I would be very frustrated to work for one. "The customer is my partner" is a step up in business maturity from "The customer is the boss". You don't want to tell your partner "No". But you can tell your partner "Yes, but it will take longer/cost more". If they don't want to be your partner, at least you had a mature relationship with them.
