Hacker News Reader

If you try this (and I have, just not with fruits), someone will complain they can't graph fruits. You'll tell them that's the point. They won't listen, so they'll map fruits to numbers, and now you have the same problem anyway.

My personal preference is to use time estimates with some uncertainty. A day or less. 2-3 days. A week at most.

View on HN

> My personal preference is to use time estimates with some uncertainty. A day or less. 2-3 days. A week at most.

In the project management world, there is an assumption that tasks that are overestimated and underestimated would even themselves out so that the total estimate would equal the actual time needed. Sad to say that accuracy of estimates don't follow normal distribution in software development.

I had one manager who used time in orders of magnitude. He’d ask, “is it a day, a week, a month, or a year?”

I've done exactly this in the past, and then when someone asks how long the project as a whole is going to take it's easy enough to give a range. If someone says a task is going to take hours that's a range of 1-6 hours, if they say it's months that's 1-12 months. If you want more certainty in your estimate then you're going to have to give us some time to break things down.

Reply on news.ycombinator.com