Multiply By Nine

Some people say Multiply By Three. I have found three times three to be a good number. I learned it from my own estimates for my own work, then found a project manager who had used it for years, now I apply it to other projects.

What he said was, "I multiply by three if one developer is talking, and multiple by another three if there are a group of developers." I find for me, I underestimate the size of the work by three, and overestimate my productivity by three. Here is a story from a recent project, otherwise described in NotTooMuchMeasurementDetail...

Our sponsors got (quite reasonably) very upset when they saw our schedule and work estimate, because it was nine times larger than the previous estimate. The previous estimate was made by two of the developers, who did the usual caveats: this is the number of work-days in PerfectWorkDays, not including testing, documenting, etc. You multiply x3 to get Real Days, x3 to cover the non-design parts, and voila, x9 is an appropriate answer.

--AlistairCockburn

Most every XP project I've seen has velocity about equal to 1/3 number of programmer days, not 1/9. I've never seen one at 1/9, although I know where I'd go to find one. I wonder what the diff is. --RonJeffries

Multiply by x for the size of the entire project, maybe. For individual milestones / subtasks, optimistic estimates are good, provided nobody's going to be punished for missing them - keep your padding at the end of the critical path, and maintain the feeling that any given task needs to be finished as soon as possible, to avoid Parkinsonian fattening on the way. See Tom DeMarco's *Slack* and Eliyahu Goldratt's *Critical Chain* for better-worded justification. -JamieFristrom

MythicalManMonth has a different MultiplyByNine heuristic for programming system products.