My Approach to Estimating

I did some research on using function point counting on an XP project many years ago. A few people remember that paper and occasionally I'll be asked what approach I recommend these days for estimating. There is a lot to like about function point counting and it can be useful on an agile project for estimating a whole project (but not an iteration for reasons explained in the paper).

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.

Bootstrapping

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.

Question

On a related topic, tell me, do you have only the developers participate in estimating or does QA participate too?