1

I'd like to get better at estimating how long it will take me to complete tasks. When estimating things I know little about, I think it's best to start with base rate information and adjust it based on things I do know, rather than to go on 'gut feeling' which is what I normally do, and is generally optimistic. What I lack is that base rate information.

Are there any statistics available which give typical ideal man-hour costs (or some other metric) based on some property/properties of the task in question?

For some context, I work as a programmer in the video games industry, and I'm talking about chunks of work that typically take somewhere between 2-16 hours, though occasionally drag on far longer than that... ;)

I realise this is a big ask, but I have to start somewhere!

Things I've already tried:

  • google - my search terms appear to be too general - lots of irrelevant results.
  • This question - asks for overall estimate, in a different domain. Unsatisfactory answers.

closed as off-topic by gnat, GlenH7, Ampt, user40980, Kilian Foth Jul 30 '14 at 8:31

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – gnat, GlenH7, Ampt, Community, Kilian Foth
If this question can be reworded to fit the rules in the help center, please edit the question.

  • Several one-day tasks would require several weeks of refactoring/recoding.... – Basile Starynkevitch Jul 17 '14 at 18:58
2

I don't know of any useful statistics on how long a task takes and I doubt that they would help you.

The best way to get better at estimating is to do it a lot and to evaluate why the actual time deviated from the estimate.

This all depends on knowing the estimate you gave, what you considered to be included in the task when estimating, the actual time it took to complete the work and what the task actually entailed.
With that information, you can find consistent deviations in your estimations and/or sub-tasks that you consistently forget in your estimate.

For example, I found after a number of estimations that I consistently underestimate the amount of work by a factor of 8 and that the number that pop into my head is typically only for the coding itself, without testing and documentation. What I do nowadays is, if I initially think a task will take 2 hours, then I give 2 days as my estimation to the team. So, I simply multiply my gut feeling with the factor that I know to usually be off by.

Another way to get better estimations is to base your numbers on the actual time it took to complete similar tasks.

  • You're implying then that you can't learn from other people's estimation? In truth that's what I suspected anyway, I was just hoping that given the size of the field there would have been some effort to pull together some data :) – Ben Hymers Jul 18 '14 at 0:34

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