Time Estimates - Black Art? [modified]
-
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
-
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
Trust your gut feeling and dont over-estimate yourself or under-estimate the problem.**
xacc.ide-0.2.0 preview - Now in 100% C# goodness
**
-
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
Keep records as you go and this provides the figures for future estimates. Learn as you go and hopefully from others too. Elaine :rose: The tigress is here :-D
-
Keep records as you go and this provides the figures for future estimates. Learn as you go and hopefully from others too. Elaine :rose: The tigress is here :-D
That seems to be the jist of it. Document and learn. This statement is false.
-
"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
But do you really have control of this? Making demands looks good on paper and may be the right thing to do, but how often is it successful? 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
-
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.
Actually it is just a random thought.... Never tested or put into trial. It is just based on two components for developing a software project. The first component where the "a" constant associated tells the extra features needed or underestimation of the development time of each module. The second component where the "b" constant associated tells the interdependence of the modules, coz one module fault may lead to another module fault, and there will be iterations of work around and around, so lead to a result those order related to a factorial function or exponential function.
-
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.
-
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:
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.
If there is already a date then what is the estimate for? :confused:
Chris S Kaiser wrote:
and it exceeds the date promised to the client, it could effect the renewal of the contract.
Sounds like you are "bidding" again. :confused:
Chris S Kaiser wrote:
But the effort to get at accurate estimates is what this is about.
An "accurate" estimate is only obtainable from "accurate requirements". Anything else is just a "guess" not an estimate.
-
But do you really have control of this? Making demands looks good on paper and may be the right thing to do, but how often is it successful? This statement is false.
I am not speaking to the "political" and "business" aspects of this issue. It was not clear to me that was your question. I was speaking to the "science" of software estimating. The science is simple and the business either supports it or it does not. If it does then a accurate scientific estimate can be produced. If not then whatever is stated verbally or on paper is done so from the perspective of "business" and has nothing to do with scientific accuracy, period. They are two completely different things.
-
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
Since we started using agile programming / XP I've found out estimates are now infinitely better than estimating projects completely ahead of time.
-
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:
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 would say I'm pretty good at it. My methodologies are basically to drill into the requirements, putting together both a confidence level and a time estimate. If the confidence level is low, I drill further. If that's not possible, and often it isn't, at least I can say to my client that I don't really have any way of estimating the time here without spending time to do further analysis. This happens often enough when dealing with new technologies, or the requirements simply can't be defined yet, etc. And lastly, after all the analysis, I follow the "Ross Rule of PI", named after a hardware guy I used to work with. I multiple all estimates by 3. Seriously. This helps to factor in testing, documentation, bug fixes, refactoring, etc. It also makes me look like a miracle worker (a la Scottie of Star Trek) when I get things done in less time. :) [edit] Oh, and one more thing. I also break the project up horizontally into milestones, and I tell my clients, we will revisit the time estimate for each milestone after completing the preceding one. It's interesting you posted this question. After responding to your other post, I was beginning to thing, this would be a good article. [/edit] Marc Pensieve
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
-- modified at 16:49 Monday 17th July, 2006
