One one hand it's easy to think in absolute measures like days or hours (even if you call them 'points' like we do, which is another story altogether). They make for simple translations to dollar figures, target dates and so on. On the other hand thinking in relative measures like 'story points' or 'foobars' can speed up the estimation process, keep stakeholders from nickel-diming on estimates and generally reduce some of the headaches that arise from talking in absolutes.
To get a better handle on which strategy is more suitable for agile development we're going to take a look at parts of a typical project timeline where estimation comes into play to help us decide which approach is better. Depending on the way your organization is laid out this may not match your experience but hopefully it provides some insight.
Funding
In our environment, when funding is being secured for a project the requirements usually haven't been fully baked. We're asked to provide some high level estimates on really raw requirements, primarily so we can secure enough funding to provide a solid set of features that can go in the next big release. Absolute numbers are needed so they can be translated to dollars, head counts and timelines.
Our team usually pulls a few engineers together to throw some high numbers on the rough requirements. Not very precise, but generally it's accurate enough. In contrast, some teams we've worked with do relative 'shirt-size' estimates (x-small, small, medium, large, x-large), apply day/week values to them and multiply them out to get the absolute numbers. That's most likely a bit more accurate.
Verdict: At this point, really whatever works.
