[Boulder.pm] one piece of advice

Evelyn Mitchell efm at tummy.com
Mon Dec 16 23:24:56 CST 2002


* On 2002-12-17 04:50 Rob Nagler <nagler at bivio.biz> wrote:
> 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.

I tend to go a lot finer than this. I'll estimate down to the hour level.
But then, the sorts of things we do frequently tend to be completable in an
hour or two. If someone says "This is going to take 2 days", I know they're
not clear on what needs to be done for it to be all done.

> 
> >    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 takes a fair bit of discipline. It's still important to add time to the
task record, even if you're switching around. Each of us records our time
using a standard format, and I keep a database of that. Just the simple
task of doing something when task switching can be very helpful to build
awareness of how long things actually take, or how many interruptions you
have.

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

Yup, that's a good one too.

> 
> > 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."

I like this because it puts the risk in the right place. If I don't know
how long something is going to take, then I have to tell the customer, or
they think I know something I don't. If I communicate clearly, then the
customer can decide, based on their needs and budget, whether this portion
is something they need or want.

> 
> 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. $-(
> 

Customers can manage the risk they know (their schedules, their budgets,
their business goals), and I can manage the risks I know (estimating how
long a task will take, knowing my tools, knowing my resources). The thing I
like best about XP is that it is so clear about separating these types of
risks.

It was so arrogant of IT people to think they could know what customers
needed without asking them. But for many years, it seemed the only way to
build systems was to make it up without asking customers. I hated that type
of thing because I knew I didn't know anything about what customers needed,
and so I thought I was a bad developer. I'm glad things are changing.

-- 
Regards,                    tummy.com, ltd 
Evelyn Mitchell             Linux Consulting since 1995
efm at tummy.com               Senior System and Network Administrators
                            http://www.tummy.com/



More information about the Boulder-pm mailing list