Time Estimates - Black Art? [modified]
-
Chris S Kaiser wrote:
or a lack or good requirements.
Then what did you base your estimate on? :~
led mike wrote:
Then what did you base your estimate on?
A limited set of requirements. I also said "should" and other approximating terms. But its always interpreted as a deadline. So a secondary question is what do you do when forced to give an date when requirements are lacking when demanding more might be a detriment to retaining the project? This statement is false.
-
Chris S Kaiser wrote:
or a lack or good requirements.
Then what did you base your estimate on? :~
Bad requirements?
-
led mike wrote:
Then what did you base your estimate on?
A limited set of requirements. I also said "should" and other approximating terms. But its always interpreted as a deadline. So a secondary question is what do you do when forced to give an date when requirements are lacking when demanding more might be a detriment to retaining the project? This statement is false.
I would say that based on your own experience, you should offset your time by the typical amount you're off. If you're consistently 30% late, then add 30%-40% to your estimate.
-
Alright, how many of you claim to be skilled in this area, and what are your methodologies for ensuring accuracy, or at least coming close? I fall victim to the "Can-do" approach. Mostly from some vain need to please. :doh: But half the time I really do think I can get it done in that time, but there always seems to be something that pops up to stall release, whether its an obscure bug or a lack of good requirements. Or something else altogether? This statement is false. -- modified at 13:06 Monday 17th July, 2006
Chris S Kaiser wrote:
what are your methodologies
Personal Software Process.
Chris S Kaiser wrote:
there always seems to be something that pops up to stall release, whether its an obscure bug or a lack of good requirements. Or something else altogether
That always seems to happen, and I try to add onto my estimates to compensate for any unseen issues that may crop up.
-
Chris S Kaiser wrote:
what are your methodologies
Personal Software Process.
Chris S Kaiser wrote:
there always seems to be something that pops up to stall release, whether its an obscure bug or a lack of good requirements. Or something else altogether
That always seems to happen, and I try to add onto my estimates to compensate for any unseen issues that may crop up.
What's your typical padding range? Is it a blanket approach like double it and add 3, or is more specialized to the project? And mostly I'm concerned with new development, and major enhancements that might require refactoring to the base architecture. Smaller enhancement requests and bug fixes to an existing app haven't been too troublesome. This statement is false.
-
Alright, how many of you claim to be skilled in this area, and what are your methodologies for ensuring accuracy, or at least coming close? I fall victim to the "Can-do" approach. Mostly from some vain need to please. :doh: But half the time I really do think I can get it done in that time, but there always seems to be something that pops up to stall release, whether its an obscure bug or a lack of good requirements. Or something else altogether? This statement is false. -- modified at 13:06 Monday 17th July, 2006
Try reading Painless Software Schedules[^]. Basically, if you can break the task down into small pieces (say 2 days work or less), you've a far better chance of coming up with an accurate estimate. Anna :rose: Currently working mostly on: Visual Lint :cool: Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.
-
What's your typical padding range? Is it a blanket approach like double it and add 3, or is more specialized to the project? And mostly I'm concerned with new development, and major enhancements that might require refactoring to the base architecture. Smaller enhancement requests and bug fixes to an existing app haven't been too troublesome. This statement is false.
Chris S Kaiser wrote:
What's your typical padding range? Is it a blanket approach like double it and add 3, or is more specialized to the project?
Most of the projects I have done for one of my clients are similar to previous projects done for them. I typically put about 25% overage on time estimates.
Chris S Kaiser wrote:
mostly I'm concerned with new development, and major enhancements that might require refactoring to the base architecture
I have those concerns, too. You are not the only one :)
-
Alright, how many of you claim to be skilled in this area, and what are your methodologies for ensuring accuracy, or at least coming close? I fall victim to the "Can-do" approach. Mostly from some vain need to please. :doh: But half the time I really do think I can get it done in that time, but there always seems to be something that pops up to stall release, whether its an obscure bug or a lack of good requirements. Or something else altogether? This statement is false. -- modified at 13:06 Monday 17th July, 2006
I have found this to be a good resourceSoftware Estimation: Demystifying the Black Art (Best Practices (Microsoft)) [^] Although the Best Practices and Microsoft seem to be in conflict ;P
-
Try reading Painless Software Schedules[^]. Basically, if you can break the task down into small pieces (say 2 days work or less), you've a far better chance of coming up with an accurate estimate. Anna :rose: Currently working mostly on: Visual Lint :cool: Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.
Good article. So really we need to be gathering statistics ongoing as to how long it took at the task level vs the project level to get a bearing on where the estimates are failing. This last one isn't that bad. I'm late by about 8 hours or so. Better than a month, but even this grates on me. This statement is false.
-
I have found this to be a good resourceSoftware Estimation: Demystifying the Black Art (Best Practices (Microsoft)) [^] Although the Best Practices and Microsoft seem to be in conflict ;P
Ahhh.. McConnell... I have a couple of his books already, but this one looks promising.
Mark Nischalke wrote:
Although the Best Practices and Microsoft seem to be in conflict
Funny, in terms of their practices I agree, at least what limited visibility I have, but they seem to churn out some of the better books regarding process. This statement is false.
-
Alright, how many of you claim to be skilled in this area, and what are your methodologies for ensuring accuracy, or at least coming close? I fall victim to the "Can-do" approach. Mostly from some vain need to please. :doh: But half the time I really do think I can get it done in that time, but there always seems to be something that pops up to stall release, whether its an obscure bug or a lack of good requirements. Or something else altogether? This statement is false. -- modified at 13:06 Monday 17th July, 2006
How good an estimator are you?[^] Apparently from the Software Estimation: Demystifying the Black Art book.
0 bottles of beer on the wall, 0 bottles of beer, you take 1 down, pass it around, 4294967295 bottles of beer on the wall. Awasu 2.2.2 [^]: A free RSS/Atom feed reader with support for Code Project.
-
Alright, how many of you claim to be skilled in this area, and what are your methodologies for ensuring accuracy, or at least coming close? I fall victim to the "Can-do" approach. Mostly from some vain need to please. :doh: But half the time I really do think I can get it done in that time, but there always seems to be something that pops up to stall release, whether its an obscure bug or a lack of good requirements. Or something else altogether? This statement is false. -- modified at 13:06 Monday 17th July, 2006
I just think of a formula for estimating the extra buffer time that being added to a project for time estimation consider the project comprised of modules : extra buffer time = a*(overall time to complete each module) + (degree of coupling within modules)^b where 0 < a < 1, and 1 < b < 3 cheers
-
Alright, how many of you claim to be skilled in this area, and what are your methodologies for ensuring accuracy, or at least coming close? I fall victim to the "Can-do" approach. Mostly from some vain need to please. :doh: But half the time I really do think I can get it done in that time, but there always seems to be something that pops up to stall release, whether its an obscure bug or a lack of good requirements. Or something else altogether? This statement is false. -- modified at 13:06 Monday 17th July, 2006
IMHO, this is more art than science. I tend to take the available information, even if incomplete, estimate how long it would take me to do averaging 7 working hours a day (8 minus time for answering emails, phone calls and meetings), and then after I get a value, I add in another 20-40% depending on how certain I am about the estimate. That extra percentage does not include the normal "padding" that program/project management should do.
Other thoughts, take 'em or leave 'em...Never give an estimate including crunch time. Sometimes crunch time is necessary, but often it really is not. (Crunch time is almost always the result of a mistake in planning or design.) Never build an estimate around more than the amount of work per day that you normally accomplish. If you do, you will just be creating unnecessary stress for yourself, and the quality of your work (and perhaps personal life) will suffer. Even though you may be capable of being super-productive every now and then, you likely cannot sustain that kind of output for a long time without burn-out, and you do not want management expecting that kind of output all the time. The most important thing you can do when giving an estimate is to remind all parties involved that it is an estimate, and not a firm deadline. An estimate is nothing more than a Hypothesis, and is subject to revision over time as more information is discovered, or Real Life intercedes. As such, some people need to be reminded that it is inappropriate to make any firm commitments based on it. If people want a firm number, give them something that you cannot possibly miss (unless you are dead or in an extended hospital stage) - if you think it would take 3 months, tell them 12. :) One of the biggest problems that I see happening to developers is when they allow themselves to get painted into a corner by getting forced by their management to reduce an estimate or give a firm value with without enough information. Lastly, and most importantly, if ANYTHING the estimate is based on changes (like a spec/design change, change of staff/resources, etc.), the estimate immediately becomes invalid! Sadly, people sometimes need to be reminded of that... Peace! -=- James
If you think it costs a lot to do it right, just wait un
-
IMHO, this is more art than science. I tend to take the available information, even if incomplete, estimate how long it would take me to do averaging 7 working hours a day (8 minus time for answering emails, phone calls and meetings), and then after I get a value, I add in another 20-40% depending on how certain I am about the estimate. That extra percentage does not include the normal "padding" that program/project management should do.
Other thoughts, take 'em or leave 'em...Never give an estimate including crunch time. Sometimes crunch time is necessary, but often it really is not. (Crunch time is almost always the result of a mistake in planning or design.) Never build an estimate around more than the amount of work per day that you normally accomplish. If you do, you will just be creating unnecessary stress for yourself, and the quality of your work (and perhaps personal life) will suffer. Even though you may be capable of being super-productive every now and then, you likely cannot sustain that kind of output for a long time without burn-out, and you do not want management expecting that kind of output all the time. The most important thing you can do when giving an estimate is to remind all parties involved that it is an estimate, and not a firm deadline. An estimate is nothing more than a Hypothesis, and is subject to revision over time as more information is discovered, or Real Life intercedes. As such, some people need to be reminded that it is inappropriate to make any firm commitments based on it. If people want a firm number, give them something that you cannot possibly miss (unless you are dead or in an extended hospital stage) - if you think it would take 3 months, tell them 12. :) One of the biggest problems that I see happening to developers is when they allow themselves to get painted into a corner by getting forced by their management to reduce an estimate or give a firm value with without enough information. Lastly, and most importantly, if ANYTHING the estimate is based on changes (like a spec/design change, change of staff/resources, etc.), the estimate immediately becomes invalid! Sadly, people sometimes need to be reminded of that... Peace! -=- James
If you think it costs a lot to do it right, just wait un
James R. Twine wrote:
Sadly, people sometimes need to be reminded of that
Even more sadly, even when you remind them it still doesn't make any difference. For the life of me, I can't remember a time when someone has come to me with a change to the spec and when I've pointed out that it will therefore require more time to do, they've said "OK, you can have more time" :~ X|
0 bottles of beer on the wall, 0 bottles of beer, you take 1 down, pass it around, 4294967295 bottles of beer on the wall. Awasu 2.2.2 [^]: A free RSS/Atom feed reader with support for Code Project.
-
Try reading Painless Software Schedules[^]. Basically, if you can break the task down into small pieces (say 2 days work or less), you've a far better chance of coming up with an accurate estimate. Anna :rose: Currently working mostly on: Visual Lint :cool: Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.
Anna-Jayne Metcalfe wrote:
Try reading Painless Software Schedules[^].
Joel on Software always has good readings on the site :)
-
How good an estimator are you?[^] Apparently from the Software Estimation: Demystifying the Black Art book.
0 bottles of beer on the wall, 0 bottles of beer, you take 1 down, pass it around, 4294967295 bottles of beer on the wall. Awasu 2.2.2 [^]: A free RSS/Atom feed reader with support for Code Project.
Another vote.. looks like that might be my next purchase then. This statement is false.
-
led mike wrote:
Then what did you base your estimate on?
A limited set of requirements. I also said "should" and other approximating terms. But its always interpreted as a deadline. So a secondary question is what do you do when forced to give an date when requirements are lacking when demanding more might be a detriment to retaining the project? This statement is false.
-
I just think of a formula for estimating the extra buffer time that being added to a project for time estimation consider the project comprised of modules : extra buffer time = a*(overall time to complete each module) + (degree of coupling within modules)^b where 0 < a < 1, and 1 < b < 3 cheers
Kim0618 wrote:
^b [snip] where 0 < a < 1, and 1 < b < 3
Oooooh... fractional exponents. Neat. ;) How often is this accurate? Another question is when padding estimates how often is it an over-estimate? This statement is false.
-
IMHO, this is more art than science. I tend to take the available information, even if incomplete, estimate how long it would take me to do averaging 7 working hours a day (8 minus time for answering emails, phone calls and meetings), and then after I get a value, I add in another 20-40% depending on how certain I am about the estimate. That extra percentage does not include the normal "padding" that program/project management should do.
Other thoughts, take 'em or leave 'em...Never give an estimate including crunch time. Sometimes crunch time is necessary, but often it really is not. (Crunch time is almost always the result of a mistake in planning or design.) Never build an estimate around more than the amount of work per day that you normally accomplish. If you do, you will just be creating unnecessary stress for yourself, and the quality of your work (and perhaps personal life) will suffer. Even though you may be capable of being super-productive every now and then, you likely cannot sustain that kind of output for a long time without burn-out, and you do not want management expecting that kind of output all the time. The most important thing you can do when giving an estimate is to remind all parties involved that it is an estimate, and not a firm deadline. An estimate is nothing more than a Hypothesis, and is subject to revision over time as more information is discovered, or Real Life intercedes. As such, some people need to be reminded that it is inappropriate to make any firm commitments based on it. If people want a firm number, give them something that you cannot possibly miss (unless you are dead or in an extended hospital stage) - if you think it would take 3 months, tell them 12. :) One of the biggest problems that I see happening to developers is when they allow themselves to get painted into a corner by getting forced by their management to reduce an estimate or give a firm value with without enough information. Lastly, and most importantly, if ANYTHING the estimate is based on changes (like a spec/design change, change of staff/resources, etc.), the estimate immediately becomes invalid! Sadly, people sometimes need to be reminded of that... Peace! -=- James
If you think it costs a lot to do it right, just wait un
James R. Twine wrote:
The most important thing you can do when giving an estimate is to remind all parties involved that it is an estimate, and not a firm deadline.
I agree with this, but sometimes you get on a project to find out that sales already sold and promised a date to a client. And its either put yourself to the task or gamble with your employment. I'm a little tired of being the nail that stood up only to get pounded down. This statement is false.
-
Bad requirements?
"bad" requirements should NOT be estimated since you do not have the "required" information to provide an estimate. If the word bad is intended to refer to the fact that the requirements "change" then changes to requirements can effect the estimate or "timeline" of the project. Of course significant changes can amount to a completely "different" project (start over). It's not Rocket Surgery. :-D
