Programmer Friday: Estimating 101


How do you determine how much time you need to build a piece of software?

We sometimes need to know roughly how long something will take before we start working on it. This is basic product management. “This new feature will take more than four months to add to our product? Maybe we have better things to do with our time, then.” The viability of a new project, product or feature is (in part) derived from the initially estimated cost of building it.

I’ve settled on the following approach for doing estimates:

  1. Start by getting your bearings. This means doing enough design and requirement gathering up front. Talk to stakeholders and users. Play around with unfamiliar technology and tools that the work will require (for instance by building small feature spikes).
  2. Ask questions. A lot of questions. You want maximum context here, so you can eliminate assumptions and unfounded guesses. Who needs this project? How many users are expected to depend on the project? How will they use it in their workflow? Which pieces are most important? Which features can be dropped initially? How polished does the UI need to be? Can you pick technologies freely? Et cetera. Et cetera.
  3. Define the concrete tasks that must be accomplished. Each estimated task should be at most a day or two in length: tasks larger than this are usually opaque “lumps” of many tasks, which are harder to estimate accurately.
  4. Estimate each task in ideal hours: “how long would this take if I could focus on it fully?” Another approach is to use abstract or relative units, before translating the estimate back to ideal hours (The Poker Planning Game is a decent technique for this).
  5. Add up total ideal hours. Then multiply by a risk factor, to allow for Murphy’s Law. Things will go wrong in unexpected ways, so you need margins for error. My minimum is usually 1.1 (10%) – and that’s if I have a very good handle on both the technology, the requirements and most other significant factors.
  6. How much effective time do you have left when you subtract meetings, other projects, administration, overhead? Figure out how many good hours you actually have available each week, on average. Divide the total ideal hours from step 5 above by these actual hours accomplished each week. Now you know roughly how many actual weeks the work will take.
  7. Take external dependencies into consideration. Will Sue Developer be busy until week three? Will Joe Tester go for a two week holiday to Hawaii at some point? Set up the project schedule based on these constraints.
  8. At this point you should be able to come up with an estimate of when the project could be done. Note: if you are performing the estimate for someone else, don’t just give them this final number or date. You should also clearly communicate all the assumptions and guesses that went into your estimate (from the process above)

Finally, three things to keep in mind:

  • If you will not do all the estimated work yourself, make sure to include the other people working on the project when you do the estimates. Estimating is guesswork based on personal strengths, weaknesses and assumptions. You cannot hold other developers accountable to these numbers if they have not participated in the estimates themselves.
  • Revise the numbers once you get going on the project. As you start building and uncertainty drops a bit, you will be able to refine your initial guesses. Update the estimates for the remaining work, and adjust the project schedule accordingly.
  • Estimating like this works best for small projects. “But how can I know exactly which specific tasks will be required all through my enormous 3-year, 100-people project?”. Well, you can’t, really. For larger projects, estimating in such fine grained tasks becomes impractical. This is due to A) the sheer scope of things to consider, and B) that concrete dependencies, time available, schedules and dependencies are unknowable that far in advance (this is why large fixed cost projects are such a bad idea).

Estimate work up front, but please treat it like what it is: educated guesswork.

In my next blog post I go into some techniques I use for estimating Android/app projects specifically.