Hacker News Reader

How else would one forecast?

If you need to accomplish TaskX, you work with the team that will do TaskX to come up with a valid estimate of effort required to complete it -- say, 300 hours of work.

You could just naively assume that this task would then be done in 300 hours / 8 hours per day / # of workers, but that assumes 100% productivity -- which isn't true basically anywhere.

Ergo...

View on HN

Even if you are estimating your own tasks and there aren't many unknowns, as a developer I don't normally check in with myself every hour and ponder how much I've achieved, so my idea of how much I can do in an hour is not going to be too accurate. Then multiply the error by 300. At least if a team has daily standups they'd be used to assessing their progress per day.

(Nice name)

The thing is, though, for many business models being able to accurately estimate time and cost is critical, and so is executing vs. that estimate.

It's nice to be able to say "I have no idea how long this will take," but it's also a luxury not available to many (most?) developers.

I doubt the manager focused on the hours. It was a simple way to say the manager doubled the expected timeframes when estimating tasks. By assuming the team is productive 1/2 the time, the task should take 2x the initial estimate.

Reply on news.ycombinator.com