|Perl: the Markov chain saw|
As software developers, we have a reputation as a group for making pretty lousy estimates. Part of that rap is unfair; many times the requirements that we're asked to provide estimates for are vague, and change as the work progresses. But a large part of that reputation is true. We make lousy estimates, and we don't seem to get much better as we go. One problem is that the feedback loop between the estimate and the achievement is often quite long. When you don't begin working on a task until weeks or months after you estimate that work, the original mental context has been lost, making it difficult to use feedback to learn.
Here's a way you can begin to shorten that feedback loop right now, and put yourself on the track to becoming a better estimator. All you need is a stack of 3x5 cards and something to write on them with.
It works like this: Keep a few 3x5 cards in your pocket. Before you begin a task, pull out a card and jot down a short description of the task on the front of the card. Short is good--you only need enough to recognize the task or jog your memory later. (My latest card is titled simply "sendarticle.cgi?article=". The one I'm working on now is "PM: estimating w/ cards")
Next, take a moment to think through what "done" means for the task, and what you need to do to get there. Now estimate how many hours it will take you to complete the task, and jot that down along with a confidence indicator (e.g., "Est: 0:30 H", "Est: 14 L"). Or you can go with a confidence range or a risk indicator. Your call.
If getting to this point with a card takes more than a minute, it's a clue that you need to break the task into smaller pieces. Rip up the card, break up the task, and do a new card for each. One of the secrets to better estimating is admitting when you've bitten off more than you can chew, and then backing off to take smaller bites.
As you start the task, turn the card over and note the date and start time. If you break off from the task, note the time. And so on until you're done. The back of my most recent card looks like
When you're done, total up the time and write an "Actual:" number below the estimate on the front of the card. I'd estimated 1:30 for the card above. It took 2:15, which I blame in part on the dog, who kept wandering in to my study with his squeaky toy. (Lesson learned: close study door or pad estimate with play time.)
Now, while memory is still fresh, take time to reflect on what happened. If your estimate and actual matches, great. More likely, you've earned an opportunity to improve. So think: What happened? What parts did you forget to estimate? What went harder or easier than you first thought? What could you remember to consider the next time you're estimating a task like this one? What about your environment interfered with your work, and how can you either change that or account for it in your next estimates? File the card away. If you keep a journal, jot down some thoughts.
After doing this practice for a few weeks you may notice improvement, and you may notice patterns, which can be fodder for improvement. One of my patterns is a consistent understimation for how long it will take to write a page of complex HTML and get it looking halfway decent. Taking my gut guestimate and doubling it works out about right.
We use this practice at work for iteration planning and tracking, though we use 4x6 cards and tack them up on boards. After doing the practice for a few months and seeing how it improved my estimates, I adopted it for use on home projects, using smaller cards that I can carry around in my pocket. Now, if I have have a sudden inspiration, there's always a place to jot it down.
It's a simple practice. Give it a try.
(I thought it would take 30 minutes to write this post and proof it. According to the card, it's been an hour. I've been understimating writing tasks lately...)