Story Points and Planning Poker
The best approach for estimating user stories on an agile project is planning poker cards, small stories, estimating regularly, and keeping a small set of good (well estimated) stories visible. What I mean by keeping some standard stories visible is having a BVC (or just story cards left up on the wall somewhere) for those stories that went well, that everyone agrees it was a good 1 pointer or 3 pointer. "How does this story compare to that one?" is a common refrain.
Estimating regularly (weekly or at least every other week) keeps the approach and the "standards" fresh on everyone's mind. Have a regularly scheduled (standing) meeting on the calendar.
I don't get any more complicated than that. That's good enough. It's quick and requires little special skill. Well, estimating with points and planning poker is a skill that does need to be learned, but it doesn't necessitate a class, a thick set of rules, or a software estimating tool of any kind. Sure, a class or some reading can help, but it's not necessary.
For bootstrapping an estimating process for a new team or a new project, I like Steve Bockman’s Team Estimation Game or the less formal approach I used on a project in the early 2000's which amounts to little more than collaborative sorting of story cards into simlarly sized piles. James Grenning describes another version of a similar activity.
QuestionOn a related topic, tell me, do you have only the developers participate in estimating or does QA participate too?