It was my great luck to work with two amazing engineers at Microsoft: Erik Christensen and Hervey Wilson. One of the most important lessons I learned from them was how to estimate. I’ve modified their methods to suit my needs, so don’t blame them if this doesn’t work for you.

Step 1: Write a small feature design document

This can be one page in google docs. Or a slide deck. Or even an interactive prototype. The key is that you can document the features you will be working on in a short and succinct amount of time.

Step 2: Make a spreadsheet of the tasks

I usually have the following columns: Area, Name, Priority, Hours, and Notes. I spend a lot of time here, re-working the areas and specific tasks. In general, I am done when the following is true:

No task is more than four hours

I have no more notes saying things like: “No idea how to do this.”

There are less than 80 hours in the spreadsheet. If there is more, re-scope the work to take on a smaller chunk.

How do you know if a task will take four hours (or less)? For me, that is when I can start it after breakfast and finish by lunch. You will estimate these tasks wrong - sometimes something you thought would take a couple of hours takes a couple of days. Which is why scheduling these tasks are important.

I try to schedule one four hour task a day. That gives me (in theory) twice as much time. With meetings, production bugs, and plain misestimation, this generally works out to be true. But I can also (sometimes!) accelerate development when needed by adding another engineer or working more hours.

Here’s a an example of estimating a very simple twitter clone. First, the one (ok, three) page spec describing the functionality to be estimated can be found here.