## Re: [XP] Estimating over time

Expand Messages
• ... I agree. As the team works in the same code base their efficiency should improve and could result in a shorter estimates. Likewise, improved
Message 1 of 13 , May 31, 2002
on 5/30/02 12:20 PM, Robert Martin wrote:

>> on 5/30/02 10:14 AM, Robert Martin wrote:
>>
>>> Thus, our estimate of difficulty, and our current
>>> efficiency are both variable. If you try to nail
>>> a story down to a specific number of real days,
>>> you could lose the ability to track and adapt to
>>> this intrinsic variability.

>> James Goebel replied:
>>
>> I do not understand this part.
>>
>> Because most of the teams I interact with estimate
>> using calendar days I am very interested in better
>> understanding what you think is lost in terms of

> If you estimate a story as "Calendar Days", then the estimate conflates the
> difficulty of the story with the efficiency of the team. If either changes,
> the estimate must change.

I agree. As the team works in the same code base their efficiency should
improve and could result in a shorter estimates. Likewise, improved
understanding of the code or related stories might increase the team's
estimate of story difficulty.

So
Estimated Difficulty is the team's abstract estimate
Last Measured Efficiency is the current velocity

Implying something like
Current Estimate = Estimate Difficulty * Last Measured Efficiency

And using these relationships I can create a prediction of what the team
might accomplish over the next two weeks.

> If, however, you put a dimensionless number on
> the story, and keep track of velocity, then the estimate on the card only
> changes when the team better understands the difficulty of the story. The
> efficiency of the team has no effect.
>
> Thus, when it's time to plan, you can simply say: "We got 78 story points
> done last iteration, so lets choose 78 for this iteration.". If the team
> gets cut in half you can simply say: "Hmm. With 12 people we got 78 story
> points done last iteration. But this iteration we've only got six people,
> so lets only commit to 39 story points."
>
> If you decide to make each story point a calendar day, or a man day, then
> you can set your velocity to the number of team members times the number of
> days in the iteration. Unfortunately this means that the velocity can't
> change unless the size of the iteration changes, or the number of team
> members change. It presumes that people always work at the same speed,
> irrespective of temperment and environment.
>
> What if one of the team members loses a son, or gets a divorce. What if
> there are layoffs in the company that reduce morale. What if terrorists
> attack the world trade center? These are things that affect the team in
> strange, and perhaps, unpredictable ways. If we decouple estimates from
> real-time we can track the change in velocity and do better prediction.

What if we were to ...

Have the team estimate on a logarithmic scale in order to capture only gross
differences.

Instead of detecting when the team has an improved understanding of a story,
have the team estimate all outstanding stories on a regular basis. Since we
use the estimates every two weeks, how about updating the estimates every
two weeks.

Have the customer prioritize and schedule stories according to the expected
number of completed stories for the next n iterations.

Always provide the programmers with two weeks worth of stories, according to
their own estimates. This provides them with feedback about their
estimating on a regular basis.

> Consider too that every estimate is really a probability distribution. If
> we estimate a story as a six, it's really likely to be anywhere from a four
> to an eight. That's just the way estimates are. When you sum a bunch of
> estimates of stories together, you get a similar random distribution.
> Howevever, some estimates will be high, and some will be low; so the mean is
> reasonably likely and we won't see a huge deviation from the mean. On the
> other hand, if you track stories by calendar days, then you will see a huge
> deviation in each individual story, and you'll worry needlessly about the

By doing aggregated planning in the style of the planning game the risks of
individual estimate accuracys are mitigated. But we still want to provide
accurate feedback to developers about their estimating skills. Improving
their estimating skills becomes even more important when we cannot guarantee
that the programmers will spend the rest of their career's in XP teams.

James Goebel
www.menloinnovations.com

> -----------------------------------------------
> Robert C. Martin |
> President & Founder |
> Object Mentor Inc. | unclebob @ objectmentor dot com
> PO Box 5757 | Tel: (800) 338-6716 x15
> 565 Lakeview Pkwy | Fax: (847) 573-1658
> Suite 135 |
> Vernon Hills, IL, | www.objectmentor.com
> 60061 |
> -----------------------------------------------
Your message has been successfully submitted and would be delivered to recipients shortly.