Time Estimates - Black Art? [modified]
-
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.
-
Chris S Kaiser wrote:
detriment to retaining the project?
ummmm... "bidding" is not the same as "estimating"
Nah, I'm referring to management causing trouble when you tell them that you just can't make the date that they promised a client with no requirements fleshed out yet. They might let the term of your contract finish, but not renew it, mistaking your accurate deduction of the facts for an inability to perform. 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
-
Nah, I'm referring to management causing trouble when you tell them that you just can't make the date that they promised a client with no requirements fleshed out yet. They might let the term of your contract finish, but not renew it, mistaking your accurate deduction of the facts for an inability to perform. This statement is false.
-
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.
Paul Conrad wrote:
Personal Software Process.
Did you take their training courses? Or did you read up on material to get what they offer? I'm referencing: http://www.sei.cmu.edu/tsp/psp.html 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
Systematic Wild A** Guessing. Bidding a project that will not have feature creep is so much easier because you can use past experience to guide future decisions. For any really difficult section I am oft to do a proof of concept first to get an estimate. Then you ask yourself, should you charge for refactoring? (If the refactoring is part of your incessant desire for perfection and not a requirement) noir is best suited for Friday nights with women who like such things. 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
-
By giving an estimate that is based on the facts that limited requirements require a wider estimate range that soon becomes unacceptable to management as they've already given a hard date that must be met. So, if you pad the estimate to a safe range, based on limited requirements, and it exceeds the date promised to the client, it could effect the renewal of the contract. This is hypothetical. But the effort to get at accurate estimates is what this is about. Is it better to pad it knowing you need it, or run late so that you defer dissappointment? This statement is false.
-
Chris S Kaiser wrote:
detriment to retaining the project?
ummmm... "bidding" is not the same as "estimating"
This was still estimating. I didn't bid on the project. So I don't understand your assumption that I was talking about bidding vs estimating. This statement is false.
-
Paul Conrad wrote:
Personal Software Process.
Did you take their training courses? Or did you read up on material to get what they offer? I'm referencing: http://www.sei.cmu.edu/tsp/psp.html This statement is false.
It was introduced to me in a graduate level software engineering course at the university I recently graduated from.
-
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:
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.
Aye! Scrum has also helped us come up with realistic (i.e. mostly correct) time estimates. /ravi My new year's resolution: 2048 x 1536 Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com
