[Boulder.pm] one piece of advice

[Rob Nagler]

Evelyn Mitchell writes:
>    1) I try an break the task down into the smallest pieces possible, then
>    ask 'What am I forgetting?'. This helps to avoid the scope problem.

Our story cards usually are no more than 1 day, and usually less.  We
avoid estimating any story over 1 week.  My mistake is estimating for
other people, which I have to do often.  Ain't no magic bullet for
this, I s'pose.

>    2) I track how long it took to do a task, and use that as a baseline for
>    estimating similar things in the future. 

:)  This is tough.  We try to do this, too.  When pair programming and
swapping partners often, it gets all mixed up.

> It's similar to the _Discipline for Software Engineering_ by Watts
> Humphrey, but not nearly so rigorous.

Extreme Programming eXplained by Kent Beck.

> Also, I try to be very clear about the parts of the task I'm comfortable
> estimating closely, and the parts which I'm not so sure about how long
> their going to take. 

Good advice, too.   We try to estimate the exploration phase,
e.g. "Let me look at this for two hours, and I'll get back to you."

Recent bad experience: We needed to generate a printable version
for a complex report (~50 pages).  Our initial cut was, "Hey, we can
just munge this all in HTML".  Nope.  It was much longer due to
browser ugliness and there is no table of contents.  We then tried
using pdflib.org.  This cost us a lot of time, and yielded poor
results.  We finally settled on generating LaTeX, and we're much
happier.  We estimated so badly that we ate half the cost of aborted
implementations.

That's another point (which I don't think applies to Walter :).  Make
sure you don't just dump the cost of mistakes on your customer.  Often
we do fixed bid iterations (2-3 weeks), and guarantee we'll get it
done no matter what.  Usually, we get the estimate right, but
sometimes, we get it wrong and eat the mistake.  Nothing like serious
financial pain to sharpen your mind/skills for the next time. $-(

Rob