Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Many, many moons ago I asked my mentor how to estimate. He told me that you should figure out what it feels like, then double it and then take it to the next higher time unit.

"hmm, adding that button probably takes about an hour"... 2 days is about right.

Almost 30 years later I still find this to be true. Truer than I like.



It is somewhat a self correcting system.

You don’t want them interacting with you too often for one hour tasks. You want to train them to lower resolutions slices. And you want to round up small ones to do refactoring as well.

Eventually they get a sense of just right. It’s never perfect but they are estimating before they even ask. Whic if we’re honest, they’ve done anyway and they’re hoping we will agree, absolving them of the responsibility.


> Almost 30 years later I still find this to be true. Truer than I like.

This happened 15 months ago?


So 1 Month becomes 2 years? I don't think that's a good rule.


1 month of your own concentrated work? 2 quarters easily, because at this scale:

- You’ll get a bunch stakeholders each requesting a different format of progress reporting.

- You’ll get pulled into dealing with a small but disruptive emergency that requires unique expertise.

- A dependency will change in a way incompatible with your work in progress.

- You’ll hand off the half done project to the new hire.

- You’ll need to rediscover what the project is about after the new hire hands it back.


Not that I've used this extensively, but months would likely increase to quarters.

And if you're estimating something to the lengths of months, you're already into project management territory size, rather than broken down to development/delivery sizes... The amount of unknown unknowns and other uncertainty certainly warrant happily estimating years length, surely.

Also #NoEstimates (=




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: