Estimate Like a Boss
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.
And here’s the spreadsheet of tasks for the first version.
In a future post, I’ll follow up on how to use this technique with a team of engineers.
Thanks to Amy Bond and Rohit Rajan for reviewing earlier versions of this post. Bullseye image by Christian Gidlöf