4

Another question came up about estimation of budget and time plan estimates for a project. In my answer, I stated that the ground knowledge for time estimate was experience. Does anyone knows a more rational mean to get an estimate the duration of a programming task?

Improve this question

3 Answers 3

Reset to default
4

Academically-speaking, there are several approaches to forming an estimate. The actual model used probably combines one or more of these approaches.

  1. Expert judgement - Ask someone with experience.
  2. Regression - Compare future work to past work. Here, you need to have actual durations from past work. Usually this is a mathematical model of some type.
  3. Case-based Regression - Find something similar that has a known duration and adjust for differences.
  4. Analogy - Characterize the project by attributes from similar projects.

The important thing to remember is that it is impossible to derive an exact value; Steve McConnell covers this very, very well in his book "Software Estimating: Demystifying the Black Art." Your estimates will get more and more accurate the closer you get to completion as unknowns become "knowns."

Improve this answer
3

Steve McConnel has a great book called "Software Estimating: Demystifying the Black Art." It's great. I read one chapter; he talks about multiple techniques you can use.

One is "decomposition." If your task is to code 10 widget classes, and historically it took you 2 hours to code one widget class, 2 * 10 = 20 hours estimated time.

That, along with more traditional estimates (like analogous estimating -- estimating based on similarity to a known task, three-point estimating -- using best/worst/average case estimates, etc.) should suffice you.

That, and a good ol' dose of experience.

Improve this answer
3
  • 3
    also @stephan added some sentences on my previous post which is very informative on this topic as well : "track time!! So that you can use it for the project after this one. Not only to be able to compare with previous realised work packages or tasks (if you track time on this detail), but also to track how well you're doing the estimations. If you notice that you under-estimate by a certain %, you can use that 'evidence' next time as a separate margin or even to adjust the most likely estimates." goo.gl/VqY1u
    – tugberk
    Commented Apr 4, 2011 at 20:53
  • 2
    Be careful! One result shows nothing about the quality of your DETERMINISTIC estimate. You can flip a coin ten times and get 8 heads and 2 tails. These results do not change the probability to 80/20. Chasing future estimates by using the results of a few is trying to control stochastic noise.
    – David Espina
    Commented Apr 5, 2011 at 0:02
  • Agreed. But just like you have to be careful not to focus only on the past to predict the future, you should not easily reject the lessons the past can teach us. Anyway, in my answer I talked about estimate ranges, not single point estimates.
    – Stephan
    Commented Apr 6, 2011 at 20:04
2

When you are estimating, you are trying to predict the future. There is no fail-safe way to do this. A controlled method that is iterative, performed by several "experts", using multiple approaches--e.g., historical values, parametrics, top down, bottom up--validated by a rigorous simulation will produce the most credible results. Unless you cook the books, you will not meet your target with zero variance. You will finish some in less time, and others in more time. Capture those results and use them in your analysis for the next estimation, but do not chase those numbers.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.