How do you determine how long something will take to build?
In an ideal world, many of us would probably like to simply work until the stakeholder/product owner decides we’re done, keeping our expense meter running all along. This is (very roughly) the approach taken by agile software development methodologies such as Scrum.
Unfortunately, in the real world we often need to know roughly how long something will take before we start working on it. This is basic product management: the feasability of a new project, product or feature is (in part) derived from the initially estimated cost of building it. “That new nifty feature will take more than four months to add to our product? Maybe we have better things to do with our time, then.”
What’s the best way of doing this up-front estimation? There’s certainly lots of approaches out there. Personally, I’ve settled on the following method:
- Start by getting your bearings somewhat. This means doing enough design and requirement gathering up front. Talk to stakeholders and users. Play around with any new unfamiliar technology that the work will require.
- Extract the concrete tasks that must be done. Each task should take less than eight ideal hours to complete (see below). Tasks larger than this are often opaque “lumps” of many tasks, which are harder to estimate accurately- so divide the work into subtasks as needed. Don’t forget work related to polish and testing: integration testing, documentation, release routines, etc.
- Estimate each task in ideal hours: “how many hours would this take if I could focus 100%, no interruptions, closed office?” Another approach is to estimate using abstract or relative units, before translating to actual ideal hours. The Poker Planning Game and the Pomodoro Technique are good examples of this approach.
- Add up total ideal hours. Then multiply by a risk factor, to allow for Murphy’s Law. My personal minimum is usually 1.2 (20%) - and that’s if I have a very good handle on both the technology, the requirements and most other significant factors.
- Figure out how many ideal hours you actually get done each week. How much effective time do you really have left when you subtract meetings, interruptions, lunch, motivation lapses, etc etc? Divide the hour number from step 4 by these actual hours accomplished each week. Now you know roughly how many actual hours the work will take.
- Finally, take external dependencies into consideration. Will Joe Developer be there week one or is he tied up? Will Sue Tester go for a three week holiday to Hawaii at some point? Set up the project schedule based on these known constraints.
This method is heavily inspired by Mike Cohn’s Agile Estimating and Planning, and I use it both at my dayjob and for private side projects. I’ve found this to yield quite accurate estimates for small projects - eg. where the scope is less than, say, 3 months with less than four developers.
For larger projects you may find that estimating work up in such fine grained tasks involves a lot of uncertainty. “How can I know exactly what specific tasks will be required all through my project?”. Well, yes - for projects with larger scopes, this quickly turns into riskful guesswork. This is what makes estimating entire large projects up front (and, by extension, taking on large fixed cost projects) such a dicey proposition.