Loading ...
Sorry, an error occurred while loading the content.

Re: [XP] Estimating over time

Expand Messages
  • James Goebel
    ... 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
      >> tracking and adaptation.

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

      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

      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
      > accuracy of your estimates.

      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

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