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

Re: [XP] Re: Ideal programming time (Was: Customer doesn't trust our estimates)

Expand Messages
  • Steve Bate
    ... I agree. That would be confusing. In fact, I m not even completely sure I know what you mean. :) Maybe I m missing a connotation of the word size , but
    Message 1 of 1 , Apr 1, 2003
    • 0 Attachment
      >From: "Kiel Hodges" <kielhodges@...>
      > "Ideal" makes a better target, but let me take a shot at
      > "programming time". A developer should estimate a task. He should
      > not estimate both the size of the task and how much programming
      > time will be available over the course of the task. I've seen
      > people get caught up in that double estimate.

      I agree. That would be confusing. In fact, I'm not even completely
      sure I know what you mean. :) Maybe I'm missing a connotation of
      the word "size", but for us the programming hours are the size.
      There is no dual estimate in that sense. We don't estimate the
      expected wall clock interval for each task individually. We have a
      programming hour budget that was determined using yesterday's
      weather (the programming hours tracked for the previous iteration).
      During planning, we estimate programming hours for stories/tasks
      until we've used up our budget. Simple. We then track the current
      iteration. If the actual number of programming hours was less or
      more than we predicted, that difference affects the budget for
      the subsequent iteration. The load factor can be calculated,
      but we rarely need it.

      > I'm sure teams can learn to just estimate the task, particular in
      > a healthy environment. Perhaps I am being fearful and should just
      > find my Courage. Otoh, points have served me well.

      Just to be clear, I'm not against points in general. If it works
      for some or most teams, that's great. I'd like to understand better
      if there are characteristics of teams or development contexts that
      would cause a team to choose points over programming hours or if it is
      really just a matter of preference.

      I've worked with about 25 different developers with a wide range
      of development experience on XP projects and, so far, none of them
      have had a problem with estimating in programming hours. We've
      occasionally discussed the possibility of using points and have
      decided it against it each time. One of my own concerns about
      points is how to compare stories that are very different from
      each other (e.g. adding a new business rule for interactive
      credit evaluation in a J2EE web application vs. implementing
      a Kalman filter for system state estimation). In previous
      and current discussions on this topic, there hase been
      mention of using "gut feel" to make these comparisons.
      My suspicion is that the "gut feel" is based on a (possibly
      subconscious) comparison of estimated programming time. My
      suspicion could certainly be wrong.

      I find it interesting that you believe programming hour estimation
      would require a healthier environment than point-based estimation.
      I would have thought the opposite. I suppose it depends on the
      type of "health". I'd be surprised if a micromanager who's
      suspicious of a development team's activities would respond
      well to estimates in points or gummi bear units. I've heard that
      points are supposed to protect a team against the manager demanding
      and unreasonable increase in hours during iteration planning. Of
      course, the manager can always demand an increase in points as well.
      With both points and programming hours the development team
      can play the "yesterday's weather" card, but in an unhealthy
      environment it may have little chance of being effective. Now
      that I think more about it, it seems that XP presupposes
      a relatively healthy developer/customer/manager environment.

      > > Although I agree it won't identify the causes of excessive
      > overhead,
      > > programming time per day can be a strong hint as to whether
      > overhead
      > > is even a problem or not. If a team is only able to program 2
      > > hours/day then overhead is definitely something to investigate.
      > If
      > > they are programming 5-6+ hours/day then overhead may not be an
      > > issue and it might be more effective to focus on coding
      > practices.
      > I've never needed this hint.

      I can't think of any times where this "hint" told me something I
      didn't already know. However, I have needed it several time (or
      at least it was useful several time) in highlighting excessive
      overhead imposed by management. Managers tend to be more
      responsive to quantitative data than to what they see as
      whining from development teams.

      > I've never felt the need to track productivity to identify morale
      > problems, etc. I also tend to not fret too much over some
      > variation in productivity. I don't ignore it; I note it and wait
      > to see if there is a real trend.

      I didn't mean to give the impression that we track time to identify
      morale problems. When morale problems exist, standup meetings serve
      well enough for identifying them. ;)

      > > From what I've seen on this list, most people base their point
      > > estimates on programming time anyway (at least to determine
      > their
      > > baseline "1 point" story estimate). From that perspective, it
      > seems
      > > to me that points are one or two levels of indirection
      > (baseline
      > > story plus integral multipliers) from programming time. I
      > > prefer to use the primary information.
      > I don't see points as being indirect in any way I care about. We
      > estimate in points using comparison, gut feel, etc., just as we
      > would estimate in programming hours. And we track our actual
      > velocity, just as we would if we used programming hours.

      I agree. Planning using points and programming hours are very
      similar. However, it seems to me that a key difference is the
      use of intra-iteration comparison. With programming hours you
      might estimate a task based on a similar task that you worked
      2 years ago rather than comparing it to a possibly highly
      dissimilar 1 point task in the current iteration.

      > > I'm not claiming it's
      > > better in any absolute sense but it works great for me.
      > Well, ultimately, that should count more than what a fool like me
      > has to say.

      Well, FWIW, you don't seem like a fool to me. Thanks for the

    Your message has been successfully submitted and would be delivered to recipients shortly.