(Taking you seriously) Try keeping a log of your estimations and the actual time taken. Write down both the original two day estimate and the extended 11 day one.
Then after a few months you should have a good set to look at and hopefully convince yourself to believe your modified estimates. Or how to adjust your formula to be more accurate.
I think you want the unit I always round up to: sitting-in-your-source-code-folder-unviewed-for-a-year-with-all-intentions-of-finishing-it-though-really-just-avoiding-it-because-you-know-it-is-way-too-large-to-really-finish-to-the-degree-of-polish-you-initially-envisioned.
Really the point is to keep yourself honest and realize that things tend to take a lot longer than you'd expect.
Also, if you are scoping a project out in terms of years you probably want to break it down into smaller features and implement them one-by-one.
I know a management consultant that has a surefire method of stretching a sentence into a book. He is also good at stretching the truth. I believe he helped Tim Ferris out with the four hour workweek
I once knew a project manager who took 2 pages I'd scribbled while explaining him the possible architecture of some odd project, and came up with a 150 page SRS
Comments
Here's Daniel Markham's surefire rule to estimate projects:
Take your estimate. Double the number. Then go to the next unit.
So if you think you can do it in 2 weekends, 2x2 = 4, and the next higher unit is weeks. Sounds like a four week job.
The beauty of this is that it doesn't rest in any mathematical principles at all -- it's totally made up. Just like regular project estimating.
Here's mine:
Double it, add another unit up. So, two days becomes four days + 1 week = 11 days. I've found this (depressingly) accurate over a large sample size.
The only problem is, for each new task, I refuse to accept that such a "ridiculous" estimation could be correct, so I just stick with the original.
And the cycle continues...
(Taking you seriously) Try keeping a log of your estimations and the actual time taken. Write down both the original two day estimate and the extended 11 day one.
Then after a few months you should have a good set to look at and hopefully convince yourself to believe your modified estimates. Or how to adjust your formula to be more accurate.
(agreeing), I believe that's called velocity. This skill will help any programmers while doing consulting.
I have a project I think I'll be able to do in a year, what unit should I use?
I think you want the unit I always round up to: sitting-in-your-source-code-folder-unviewed-for-a-year-with-all-intentions-of-finishing-it-though-really-just-avoiding-it-because-you-know-it-is-way-too-large-to-really-finish-to-the-degree-of-polish-you-initially-envisioned.
Really the point is to keep yourself honest and realize that things tend to take a lot longer than you'd expect.
Also, if you are scoping a project out in terms of years you probably want to break it down into smaller features and implement them one-by-one.
Sounds like a two-decade job, my friend.
I'm writing a book on the method -- as soon as I figure out how to stretch one sentence into 400 pages.
I know a management consultant that has a surefire method of stretching a sentence into a book. He is also good at stretching the truth. I believe he helped Tim Ferris out with the four hour workweek
Are you saying the book should be called the eight day workmonth?
Sounds like a cool book. I'll have to read it after I finish the 2-hour manager.
I once knew a project manager who took 2 pages I'd scribbled while explaining him the possible architecture of some odd project, and came up with a 150 page SRS
Or use the Inside Vs. Outside view: http://lesswrong.com/lw/jg/planning_fallacy/