Relative Weighting and Planning (Agile Planning Poker)

There's an excellent article expounding the benefits of relative planning at Scrum Shortcuts:

Unlike traditional estimation units such as ‘ideal days’, the measurement unit utilized during relative estimation is not time based but rather, size based. Size in this case does not have a direct relationship to a specific time duration but instead, it is a function of three factors: effort, complexity and risk. ... Relative estimation applies the principle that ‘comparing’ is much quicker and more accurate than ‘breaking down’. What this means is that instead of trying to break down a user story into component tasks and determining the task durations to obtain an estimate, the team is simply comparing the size of a new user story to the size of a previously estimated user story to obtain an estimate. Simply put, it relies on relative comparisons with known quantities rather than arbitrary units of time that are guessed. The assigned point value that a user story receives is not a time unit but rather a relative ‘marker’ compared to other previously estimated stories.

I've found relative planning to be a more accurate method of estimation and, by gathering the highest risk/pointed cards together at the start of the sprint, a simple way to assess potential difficulties before the sprint begins.