I was in a meeting today with a consultant (consulting us on internal procedures) and we went through an exercise of planning out the next three months of development. I'm not opposed at all to doing this, I think it is essential to have an understanding of what is coming next, in what order, and their relative magnitudes. I also think it is great to set goals for what you'd like to get done by certain dates. But I've always thought, to the disagreement of this consultant and some of my team members, that trying to put time estimates (even loosely in days and weeks) on implementing features (that have not been spec'd out, or even discussed at length) is a completely pointless and futile task. In my experience, by the time I get to working on it, the feature will have changed drastically or involve so much more than I could have known.
Am I off base and missing the value in spending time and energy coming up with a guess that in 2 months it'll take 8 days (taking into account HL) of my time to implement FeatureX?
It really depends on what the estimates are going to be used for and what expectations are attached.
If the estimates are used to report to management without a caveat then this can be a dangerous practice. If on the other hand they are used to do some high level planning or draft a project plan for discussion, then these estimates can be extremely useful.
We often use the term WAG (wild arse guess) for these type of estimates. They come with a possible +100%/-50% variance. As the requirements get fleshed out this estimate is moved to a Ball Park Estimate which has a possible +50%/-50% variance.