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

Re: [XP] average velocity?

Expand Messages
  • Gary Brown
    ... The problem we ve had with product and project management is setting the delivery date. Before XP, we were like many shops, work on a six month project
    Message 1 of 25 , May 3, 2007
    • 0 Attachment
      Quoting William Pietri <william@...>:

      > Jeff Langr wrote:
      >> I'm looking for thoughts about the use of a velocity *average* to
      >> establish a limit for iteration planning. I've always promoted
      >> yesterday's weather (points completed last iteration = points tackled
      >> this iteration). We have a few people here who like calculation
      >> average across all iterations and use that as a basis for planning.
      >> They also look to inject some level of "intelligence," such as
      >> adjusting for absence and/or new resources.
      > You've gotten a good variety of answers, but let me add one more.
      > For a team that's getting started or is having trouble, I usually insist
      > on Yesterday's Weather. I find it very valuable in keeping things
      > approximately sane.
      > For example, a lot of shops I've worked with have a culture of
      > unrealistic expectations, and left to their own devices would plan an
      > unrealistic iteration week after week. Because having every Friday be a
      > stressful failure is fun, apparently. Another good example is high
      > variability; if they are alternating velocities of 15 and 5, something
      > is going on. Planning for the low number gives breathing space to sort
      > out root problems, and I've never seen a team just loaf Thursday and
      > Friday rather than tackling debt or pulling something ahead.
      > Once a team regularly is completing what they set out to complete, I
      > don't care at all how they pick the next week's work. The ones I've seen
      > doing the best tend to use a variety of methods in harmony. They may
      > calculate a running average. They might adjust that number for special
      > circumstances. They'll sanity check the number against yesterday's
      > weather. And then they'll look at the work and do a gut check. And off
      > they go!
      > That said, for long-term planning, I feel a product manager should feel
      > free to use any method they can reasonably support from the data, and a
      > moving average is a good choice there. But people should be very careful
      > about letting the dreams of product managers influence the amount of
      > work a team is expected to take on. A little pressure can be a good
      > thing, but a lot of it can make a mess of the schedule.
      > Hoping that helps,
      > William

      The problem we've had with product and project management is setting
      the delivery date. Before XP, we were like many shops, work on a six
      month project for four months, then announce that we needed four more
      months. Work for three more months, then announce that we needed two
      more months, etc.

      After adopting XP, product and project management expected that we
      would immediately begin estimating more accurately. On our early
      projects, we would do an estimate, set an initial velocity, and
      announce the expected delivery date, with the caveat that in three or
      four weeks, we would provide a more accurate delivery date, based on
      our demonstrated capacity to do work.

      We sat through a lot of rather hostile meetings explaining that all
      estimates are guesses, and that if they allow us to bring more facts
      to the process, we'll get better guesses. After letting the process
      play out a few times, we were able prove that our estimates were more
      accurate. We haven't missed a delivery date in a couple of years.

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