Estimating¶

Got a question in #plone about estimation in our extreme programming project management tool. Time for some quick pointers.

Extreme programming makes a difference between stories and tasks. A story is something the customer wants in language that the customer understands. Something like "migrate squishdot weblog to quills". Tasks are the specific programmer tasks that need to be done.

• Before starting an iteration (which lasts 1-3 weeks), make a rough estimate of all the stories in that iteration. Don't go down to the hour level, just estimate them in days. It is a rough estimate, after all. After a while you get pretty good at estimating. Preferably do it with two people, to make sure you don't severely underestimate a story that could turn out to be much more tricky than you yourself suspected.
• At the start of the iteration, you add tasks to the stories. This time, you go down to the hour level. "Fixing that bug takes 3 hours, adding an extra browserview ought to be just half an hour". You probably end up with a total number of hours that pretty much matches the story's rough estimate. From now on, the rough estimate is essentially uninteresting: the more detailed estimate in hours takes over.
• If you need to give a rough estimate for a whole project, for instance because you want to put in a bid for a project, I like the following approach that I had to do recently. Make a list of things you suppose that need doing. Take an existing list if possible. Migration projects could list all existing installed products. Or take the customer's document where he explains the request. Then do the same rough estimate exercise. They'll probably be even rougher than on the story level, but that's ok. Don't get too optimistic, put in some padding. For each of those estimates, also write down a risk estimate on a 1-5 scale. It is an extra safeguard when reviewing your estimates afterwards. An update of the plone version from 3.1 to 3.2 could be "risk 2", while a move from an external oracle database to a mysql database could be "risk 5". Watch out with those high-risk items and possibly add extra padding for them.

A good extra trick is to make two estimates. We got a detailed bid request and estimated the individual bid items. To make sure we didn't miss anything, we also wrote down the rough technical things that needed doing, including estimates. We multiplied with 1.5 for admin, testing, release management and so. And ended up with a mostly similar estimate (41 against 45). Things like that improve your confidence in your estimates.