Time Estimates - Black Art? [modified]
-
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
-
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
From what I have seen, unless the project is something minor, most estimates fail to be accurate. In most cases you are either finished early (and have time to add more polish) or you are racing frantically trying to complete the project without losing your shirt. The best method to help reduce losses or loss of projects due to overbidding is to keep detailed logs of what you work on and how long it takes you to complete each task. When building an estimate, you can eye out what it took you before to complete and have a ballpark figure. Of course, this is relative to the tools you use. If you have to use tools (libraries, compilers, utilites) that have been recently updated, you may run into problems raising the costs. Other factors might apply such as working in a lower level language/technology such C++ vs a higher level, you may have less errors and greater accuracy to duplicate results the higher you go. I know for me, I dramtically reduced lots of simplistic errors which were simple typos or oversights after moving to C#/.NET from C++/Win32. Add to this, times when you work slightly outside of your norm, using a new library/technology and have to learn all the work arounds ;) Finally, after all your planning you push out your bid and in the process of doing the work, you run into a simple little bug in the OS or the technologies you are using and find it has just consumed 25% more time. This happens, and usually it means you eat it. As an example, a client need an ASP.NET app to work with MS Access. No problem, do this all the time, but I ran into an error which took time to track down about storing large data objects in Access. It is not that I did not plan the time, it was that I ran into a limitation of the technologies in use. I am not so sure that it is an "Art", but more of a "reasonable guess". The best a person can do is to keep a detailed log of every step and see how that applies to the future. Personally, I would try not give a "bid" on a large scale project, but rather in segments. Rocky <>< Latest Post: ASP.NET HttpException - Cannot use leading "..".. Blog: www.RockyMoore.com/TheCoder/[^]
-
Anna-Jayne Metcalfe wrote:
Try reading Painless Software Schedules[^].
Joel on Software always has good readings on the site :)
He sure does. :) I must admit I tend to read the Business of Software forum rather than the others these days (running a uISV gives me a vested interest! ;)) but they're all well worth a look. 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
That's great to hear. :) 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.
That's the general idea. Most of us have been bitten by inaccurate estimates and badly resourced projects, so the more we can do to improve our estimates (or disprove others!) the better. 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.
-
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
This would be a good article. Especially if it cited real-world examples of successes and failures in the process. I think two seperate sections would be needed though, one where the engineer is directly working with a client and another where the engineer has to work with internal management. It seems to me that it might be easier to convey the reality of the estimation directly with a client than with a management that thinks it can get done in the time they dictate. I could be wrong though. I like the idea of revisiting the estimate with each milestone. That and breaking it down to the task level and documenting the results. This statement is false.
