I'm a real fan of estimating things by doing relative sizing with planning poker cards. The cards mean everyone gets a say, the Fibonacci-like number sequence of the deck avoids getting bogged down in differentiating between tiny graduations in task complexity, and the relative nature of the sizing…
...well, that doesn't always work so well. The idea behind relative sizing is to take all of your user stories and say, "A is bigger than B, but smaller than C, which is about the same complexity as D". Numbers are a convenient way of doing that (we call them story points), but they have one big problem. People get really hung up on numbers.
I'm going to keep returning to this one as there are so many stories to tell (like the team that used high values on simple tasks to say, "we don’t like this, so we're going to make it too big to do") but let's get the big one out of the way. Story points are not hours.
The way I like to get round this is to take numbers out of the equation. Get your team to print out all their stories on cards and put them in a pile. Take the first one, and put it in the middle of the table. From now on, each new story from the pile must be put in one of four categories:
- Similar difficulty to an existing story
- More difficult than all of the other stories
- Easier than all of the other stories
- Between two existing stories in difficulty
You'll usually end up with a few groups of similar-size stories. (Disruptive teams sometimes like to claim every new story is bigger than all of the ones which have come before – it's best to identify this trend early and start asking for the reasons why each story is so big.)
At this point, ask the team to select a set of stories they think they can commit to over the next development sprint. Now take a set of planning poker cards and, starting at 1 for the group of smallest/easiest stories, put a number against each group. The team’s notional velocity is, of course, the total of what they've committed to. Hopefully everyone has realised that the numbers don’t have to mean anything!
(I wouldn't advise this to be the typical planning method; without the hidden voting element of planning poker, strong voices will tend to dominate the estimation.)