If you are doing detailed planning poker sessions for all of the requirements up front, you are wasting a lot of time, as in my experience, detailed project requirements simply aren't that fixed, so you spend a lot of time estimating items that you never build, or are so greatly changed by the time you build them that the initial estimate is not valid.
All estimates are guesses, but you can get better at estimating if you do it often and keep data about how accurate your estimates are. Estimation is best done at two levels, once initially on the project and another as an ongoing process within the project.
First, when asked for a project estimate - estimate at the feature level, using your experience on previous projects. Keep the data on your previous initial estimates and see how you track against them. You can do this initial estimate similarly to planning poker, but don't break the work down into tasks. Simply give yourself some big buckets (increments of a half week or week for the features could work, but not much more granular than that) to estimate. If more than one team member is estimating, don't waste time on too much discussion at this point, just go with the most pessimistic estimate rather than getting down into the weeds.
Second, as you work through your short project iterations (assuming that you do have short iterations), you pick the highest priority items and estimate them at the task level (and of course develop and deliver them). Once you've cycled through that first iteration you can see how accurate your detailed estimates are, as well as how they compare to your initial ballpark estimates. Now you can revise those initial estimates as you see how accurate they are, and once you have a few cycles under your belt you can give a confidence interval for the project completion date.
The units for the ballpark estimate are a good communication tool for the precision of the estimate. Your initial units are in days or weeks, but your detailed estimates are in hours.
