I think estimation can mostly be forgotten. The planning part which the author identifies is always helpful. Sure, get the team together to plan features and get a feel for the goals. Even get biz analysts together with folks to determine req's.
But do we really have to tell you how long it will take? When a lot of managers just take the estimate and multiply by three can these estimates really be trusted? What's the end game? Is it any different than just building it out? If you have a hard set of features then it will get done when it gets done. Just predict what half of what year. If you're an agile enterprise, then timebox the release and build out from there. Why must we all do this absurd dance of time estimating?
The goal is be able to effectively load-balance and prioritize. If something won't take long, for example, it can be deferred (if needed) if it depends on something else that will.
Additionally, depending on the market and how important schedule is, it lets you know if the project will be hopelessly late and as a result whether it should be canned.
Any project whose only value comes from being there first is a loser and should be canned before the estimating.
"Hey Sergei, Larry says Alta Vista is on track to beat us to market, so lets scrap this search thing and invest in new DRM schemes"
Time to market sensitivity does not always mean "loser".
An example that comes to mind (because a story about it was on HN in the last day) is that the first edition of Warcraft was aimed for the 1994 Christmas season. If it had arrived 2 months late, they would have missed that season, and technology improves quickly enough that they would have been unlikely to be as successful if they delivered the same product in the 1995 Christmas season.
Do you think that Warcraft is a product that is a loser and should have been canned immediately because they had a schedule that they really needed to deliver it on?
But do we really have to tell you how long it will take? When a lot of managers just take the estimate and multiply by three can these estimates really be trusted? What's the end game? Is it any different than just building it out? If you have a hard set of features then it will get done when it gets done. Just predict what half of what year. If you're an agile enterprise, then timebox the release and build out from there. Why must we all do this absurd dance of time estimating?