Ask HN: How do you effectively predict how long a task will take?
8 comments
I found the agile practice of estimating a task's complexity along a Fibonacci scale (1, 2, 3, 5, 8, 13) and then multiplying it by a conversion factor based on my proficiency (or familiarity with the code base) has worked best for me—since clients aren’t typically familiar with agile methodologies!
For example, let’s say I’m working on an app and estimate task A as having a complexity of 5. Because I was the primary author of the app, I use a conversion factor of 2 hours/complexity unit, yielding a time estimate of 10 hours.
The idea here is to leverage the fact that engineers have a better grasp of complexity, while business stakeholders can only appreciate time.
Keep track of your estimates over time and you can adjust the conversion factor accordingly (higher, lower, or even using days instead of hours) for more accurate predictions going forward.
For example, let’s say I’m working on an app and estimate task A as having a complexity of 5. Because I was the primary author of the app, I use a conversion factor of 2 hours/complexity unit, yielding a time estimate of 10 hours.
The idea here is to leverage the fact that engineers have a better grasp of complexity, while business stakeholders can only appreciate time.
Keep track of your estimates over time and you can adjust the conversion factor accordingly (higher, lower, or even using days instead of hours) for more accurate predictions going forward.
If you're only concerned about metrics on some bossware, overestimating seems acceptable if you lack the experience to accurately fashion a real timetable, and with time, you'll do it better and better.
If you're working with humans you can overshoot, which will make you look great if you take less time than estimated, or just say you'll give an estimate once you've started the task, they should understand (Consider using: "How long? Let me look into it first", "How long? About $(your_bad_estimate)*1.5 minutes" or similar). And if they don't understand, consider asking why that estimate is so important in the first place.
Maybe the customer must approve jobs before they are executed, and the customers get an estimate billing based on your estimated time? A big estimate might scare them. Who knows?
If you're working with humans you can overshoot, which will make you look great if you take less time than estimated, or just say you'll give an estimate once you've started the task, they should understand (Consider using: "How long? Let me look into it first", "How long? About $(your_bad_estimate)*1.5 minutes" or similar). And if they don't understand, consider asking why that estimate is so important in the first place.
Maybe the customer must approve jobs before they are executed, and the customers get an estimate billing based on your estimated time? A big estimate might scare them. Who knows?
Experience have given me an intuition of what incomplete information feels like.
And the expectation that the future always involves change...this is information I am always missing. I think about my estimate on two time scales, wall clock time and calendar time. Clock time is the resources I will need to commit. Calendar time is the external dependencies.
But, all that said, the only way to get the experience for having intuition is by estimating.
And basically, your choice (and mine) is to come up with something that might be wrong after a long arduous process or come up with something that might be wrong quickly.
Quickly provides empirical feedback faster.
Good luck.
And the expectation that the future always involves change...this is information I am always missing. I think about my estimate on two time scales, wall clock time and calendar time. Clock time is the resources I will need to commit. Calendar time is the external dependencies.
But, all that said, the only way to get the experience for having intuition is by estimating.
And basically, your choice (and mine) is to come up with something that might be wrong after a long arduous process or come up with something that might be wrong quickly.
Quickly provides empirical feedback faster.
Good luck.
determine the smallest number that your sure is larger than the true answer. (2) determine the largest number that you are sure is smaller than the true answer. (3) take the geometric average of the two. (i.e., sqrt(a * b))
The reason this does well, is that oftentimes, (1) overestimates the true answer by roughly the same multiplicative factor as (2) underestimates the true answer by. So the geometric mean cancels the over and under estimates in order to get an estimation that does pretty well.
My company has developed a spreadsheet based on actual historical effort that spits out a SWAG (Scientific Wild-Ass Guess). Things are split up into different categories, as building with one technology could be more costly than building with another. It has been remarkably accurate as long as we can stay within the original scope.
Tangentially I find it best with these things to work with a trustworthy and flexible team. That way if my good-faith estimate was way off they can communicate that to the client and make room for the surprise work.
If it's not something you can scope out when the task is brought up, you can specify how much time it would take you to research it in more detail to get an estimate.
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
I usually take my prediction, multiply the time by 2 and add another 1/4 of the time to it.
If it turns out to be faster, win-win for everyone. But usually, my guess is quite accurate that way.
I usually take my prediction, multiply the time by 2 and add another 1/4 of the time to it.
If it turns out to be faster, win-win for everyone. But usually, my guess is quite accurate that way.
Personally, it stems from tasks in the past that have turned out to have details or foibles that make it considerably more involved than initially predicted, or finding a lack of required information once I've got stuck in.