perlmeditation
dws
<p>
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.
</p>
<p>
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.
</p>
<readmore>
<p>
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")
</p>
<p>
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.
<p>
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.
</p>
<p>
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
<code>
2/9/05 2/11/05
------ -------
9:15pm 8:45pm
10:45pm 9:30pm
</code>
</p>
<p>
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.)
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
It's a simple practice. Give it a try.
</p>
<p>
(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...)
</p>