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

RE: [XP] average velocity?

Expand Messages
  • Charlie Poole
    Hi Jeff, ... Are you implying that there are folks other than the team itself who are deciding on the velocity to use in planning? If so, I d suggest this is a
    Message 1 of 25 , May 2, 2007
    • 0 Attachment
      Hi Jeff,


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

      Are you implying that there are folks other than the team itself
      who are deciding on the velocity to use in planning? If so,
      I'd suggest this is a bad idea. The most important thing about
      the number of points to be placed in an iteration is that the
      it be a number the team has committed to.

      Charlie
    • Ron Jeffries
      ... Been there, done that. No one really believed the results. Far better, in my opinion, to look each other in the eye, look at the list of what s to do, and
      Message 2 of 25 , May 2, 2007
      • 0 Attachment
        Hello, Jeff. On Wednesday, May 2, 2007, at 11:52:04 AM, you 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.

        Been there, done that. No one really believed the results. Far
        better, in my opinion, to look each other in the eye, look at the
        list of what's to do, and commit, as a team, to do it.

        Ron Jeffries
        www.XProgramming.com
        Adapt, improvise, overcome.
        --Gunnery Sergeant Tom Highway (Heartbreak Ridge)
      • Gary Brown
        ... Ron, how could you possibly suggest that I commit to my team to get something done. I
        Message 3 of 25 , May 2, 2007
        • 0 Attachment
          Quoting Ron Jeffries <ronjeffries@...>:

          > Hello, Jeff. On Wednesday, May 2, 2007, at 11:52:04 AM, you 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.
          >
          > Been there, done that. No one really believed the results. Far
          > better, in my opinion, to look each other in the eye, look at the
          > list of what's to do, and commit, as a team, to do it.

          <sarcasm mode="dripping" tone="whiny" volume="loud" duration="long">
          Ron, how could you possibly suggest that I commit to my team to get
          something done. I want to do, whatever I want to do, whenever I want
          to do it, any way I want to do it. Those stories aren't the most
          important thing right now anyhow. I just found this new tool that is
          so cool. I have to find a way to use it in all of our applications.
          And besides, there are a kazillion reasons why I might not be able to
          get that stuff done. The only sure way for us to get those stories
          done, is to buckle down, follow the team practices, and get to work.
          You can't really, seriously, expect us to do *that*, can you. This is
          really just another sinister management plot intended to force us to
          do some work, isn't it? Come on Ron, admit it! You're trying to
          impose responsibility and accountability on us. Management around
          here is so stupid. They just don't get it. We're a self-directed team!
          </sarcasm>

          8^)

          GB.
        • Jeff Langr
          Hi Charlie, Thanks for the response. ... I m interacting with a large number of teams, each deciding their own velocity, so no, to answer your question.
          Message 4 of 25 , May 2, 2007
          • 0 Attachment
            Hi Charlie,

            Thanks for the response.

            Quoting Charlie Poole <xp@...>:
            > Are you implying that there are folks other than the team itself
            > who are deciding on the velocity to use in planning? If so,
            > I'd suggest this is a bad idea. The most important thing about
            > the number of points to be placed in an iteration is that the
            > it be a number the team has committed to.

            I'm interacting with a large number of teams, each deciding their own
            velocity, so "no," to answer your question.

            thanks,
            Jeff
          • Jeff Langr
            Greetings Ron, ... Hm. Are you suggesting that we dispense with the concept of velocity completely? thanks, Jeff
            Message 5 of 25 , May 2, 2007
            • 0 Attachment
              Greetings Ron,

              Quoting Ron Jeffries <ronjeffries@...>:
              > Been there, done that. No one really believed the results. Far
              > better, in my opinion, to look each other in the eye, look at the
              > list of what's to do, and commit, as a team, to do it.

              Hm. Are you suggesting that we dispense with the concept of "velocity"
              completely?

              thanks,
              Jeff
            • Jeff Langr
              Greetings Gary, ... Thanks for the response! I agree with not worrying about one-day or unplanned absences. Sounds good. I haven t seen the 3-week average
              Message 6 of 25 , May 2, 2007
              • 0 Attachment
                Greetings Gary,

                Quoting Gary Brown <glbrown@...>:
                > We use each team's rolling three week average velocity to set their
                > expected velocity for planning purposes. We do adjust for planned
                > absences, like training, conferences, and vacation. We don't adjust
                > for unplanned absences that happen mid-iteration. In an organization
                > of our size, a few people are always missing, so that lost velocity
                > washes out in the rolling average.

                Thanks for the response! I agree with not worrying about one-day or
                unplanned absences. Sounds good. I haven't seen the 3-week average used.

                Jeff
                http://langrsoft.com/agileJava
              • Cory Foy
                ... African, or European? (For those not sure: http://www.mwscomp.com/movies/grail/grail-23.htm) -- Cory Foy http://www.cornetdesign.com
                Message 7 of 25 , May 2, 2007
                • 0 Attachment
                  Jeff Langr wrote:
                  > I'm looking for thoughts about the use of a velocity *average* to
                  > establish a limit for iteration planning.

                  African, or European?

                  (For those not sure: http://www.mwscomp.com/movies/grail/grail-23.htm)

                  --
                  Cory Foy
                  http://www.cornetdesign.com
                • Jeff Langr
                  Greetings David, ... Thanks for the response! So, it s certainly clear from the four responses, each offering a different solution, that there is no hard
                  Message 8 of 25 , May 2, 2007
                  • 0 Attachment
                    Greetings David,

                    Quoting "David H." <dmalloc@...>:
                    > I like ranges. Look at the worst velocity, look at the best velocity,
                    > then make an educated guess and a good pick somewhere in that range.

                    Thanks for the response!

                    So, it's certainly clear from the four responses, each offering a
                    different solution, that there is no hard definition to how to apply
                    notions of velocity to future planning. I think one could come up with
                    potential problems that any application of velocity (or not) can
                    cause, whether they be political, motivational, or whatever.

                    The takeaway would seem to be to do what works best, and fix it when
                    it doesn't. I've had good experience with yesterday's weather, but I'm
                    not married to it. I *am* trying to challenge the notion that there is
                    one true way.

                    Jeff
                    http://langrsoft.com/agileJava
                  • Ron Jeffries
                    ... No. Ron Jeffries www.XProgramming.com The model that really matters is the one that people have in their minds. All other models and documentation exist
                    Message 9 of 25 , May 2, 2007
                    • 0 Attachment
                      Hello, Jeff. On Wednesday, May 2, 2007, at 4:15:59 PM, you wrote:

                      > Quoting Ron Jeffries <ronjeffries@...>:
                      >> Been there, done that. No one really believed the results. Far
                      >> better, in my opinion, to look each other in the eye, look at the
                      >> list of what's to do, and commit, as a team, to do it.

                      > Hm. Are you suggesting that we dispense with the concept of "velocity"
                      > completely?

                      No.

                      Ron Jeffries
                      www.XProgramming.com
                      The model that really matters is the one that people have in
                      their minds. All other models and documentation exist only to
                      get the right model into the right mind at the right time.
                      -- Paul Oldfield
                    • Jeff Langr
                      Hi Ron, ... Hm, ok thanks. Are you suggesting that we dispense with the concept of velocity for purposes of establishing a limit to commitment for an
                      Message 10 of 25 , May 2, 2007
                      • 0 Attachment
                        Hi Ron,

                        Quoting Ron Jeffries <ronjeffries@...>:
                        >> Hm. Are you suggesting that we dispense with the concept of "velocity"
                        >> completely?
                        >
                        > No.

                        Hm, ok thanks. Are you suggesting that we dispense with the concept of
                        velocity for purposes of establishing a limit to commitment for an
                        iteration?

                        thanks,
                        Jeff
                      • Ron Jeffries
                        ... I think it s worth considering. Velocity (i.e. number of stories done) is probably useful for predicting releases and for deciding how to manage scope. Ron
                        Message 11 of 25 , May 2, 2007
                        • 0 Attachment
                          Hello, Jeff. On Wednesday, May 2, 2007, at 4:50:13 PM, you wrote:

                          > Quoting Ron Jeffries <ronjeffries@...>:
                          >>> Hm. Are you suggesting that we dispense with the concept of "velocity"
                          >>> completely?
                          >>
                          >> No.

                          > Hm, ok thanks. Are you suggesting that we dispense with the concept of
                          > velocity for purposes of establishing a limit to commitment for an
                          > iteration?

                          I think it's worth considering. Velocity (i.e. number of stories
                          done) is probably useful for predicting releases and for deciding
                          how to manage scope.

                          Ron Jeffries
                          www.XProgramming.com
                          It is not because things are difficult that we do not dare,
                          it is because we do not dare that they are difficult. --Seneca
                        • David Carlton
                          ... I don t like velocity as a tool for commitment because, among other things, velocity is an average: you should be embarrassed if you don t meet your
                          Message 12 of 25 , May 2, 2007
                          • 0 Attachment
                            On Wed, 2 May 2007 16:56:49 -0400, Ron Jeffries <ronjeffries@...> said:
                            > Hello, Jeff. On Wednesday, May 2, 2007, at 4:50:13 PM, you wrote:

                            >> Hm, ok thanks. Are you suggesting that we dispense with the concept of
                            >> velocity for purposes of establishing a limit to commitment for an
                            >> iteration?

                            > I think it's worth considering. Velocity (i.e. number of stories
                            > done) is probably useful for predicting releases and for deciding
                            > how to manage scope.

                            I don't like velocity as a tool for commitment because, among other
                            things, velocity is an average: you should be embarrassed if you don't
                            meet your commitments, while you should expect to be below average
                            half the time.

                            It's not clear to me in what circumstances you need commitments to
                            delivering specific features during an iteration. (As opposed to
                            committing to do your best, knowing that sometimes you'll overdeliver
                            and sometimes you'll underdeliver.) If I were asked to do so, I
                            imagine that I'd commit to something closer to half the velocity than
                            the full velocity. Doubtless we're less consistent than is ideal, but
                            everybody has some variability.

                            This is all related to something I'm dealing with at work right now:
                            just what roadmap promises should we make to our external customers
                            over the next N months?

                            David Carlton
                            carlton@...
                          • Gary Brown
                            ... In my organization, the problem with variance in velocity is mostly (~80%) due to large stories (greater than 4 units in our case) and our failure to write
                            Message 13 of 25 , May 2, 2007
                            • 0 Attachment
                              Quoting David Carlton <carlton@...>:

                              > On Wed, 2 May 2007 16:56:49 -0400, Ron Jeffries
                              > <ronjeffries@...> said:
                              >> Hello, Jeff. On Wednesday, May 2, 2007, at 4:50:13 PM, you wrote:
                              >
                              >>> Hm, ok thanks. Are you suggesting that we dispense with the concept of
                              >>> velocity for purposes of establishing a limit to commitment for an
                              >>> iteration?
                              >
                              >> I think it's worth considering. Velocity (i.e. number of stories
                              >> done) is probably useful for predicting releases and for deciding
                              >> how to manage scope.
                              >
                              > I don't like velocity as a tool for commitment because, among other
                              > things, velocity is an average: you should be embarrassed if you don't
                              > meet your commitments, while you should expect to be below average
                              > half the time.
                              >
                              > It's not clear to me in what circumstances you need commitments to
                              > delivering specific features during an iteration. (As opposed to
                              > committing to do your best, knowing that sometimes you'll overdeliver
                              > and sometimes you'll underdeliver.) If I were asked to do so, I
                              > imagine that I'd commit to something closer to half the velocity than
                              > the full velocity. Doubtless we're less consistent than is ideal, but
                              > everybody has some variability.
                              >
                              > This is all related to something I'm dealing with at work right now:
                              > just what roadmap promises should we make to our external customers
                              > over the next N months?
                              >
                              > David Carlton

                              In my organization, the problem with variance in velocity is mostly
                              (~80%) due to large stories (greater than 4 units in our case) and our
                              failure to write our stories as vertical slices. We have been
                              emphasizing these two ideas over the last three months, and we have
                              seen a calming of our velocity fluctuations.

                              GB.
                            • David Carlton
                              ... Yeah, we went through exactly the same problem a couple of years ago. It s played a role in our recent problems, but they ve also had other causes: a team
                              Message 14 of 25 , May 2, 2007
                              • 0 Attachment
                                On Wed, 02 May 2007 16:45:50 -0500, Gary Brown <glbrown@...> said:
                                > Quoting David Carlton <carlton@...>:

                                >> If I were asked to do so, I imagine that I'd commit to something
                                >> closer to half the velocity than the full velocity. Doubtless
                                >> we're less consistent than is ideal, but everybody has some
                                >> variability.

                                > In my organization, the problem with variance in velocity is mostly
                                > (~80%) due to large stories (greater than 4 units in our case) and our
                                > failure to write our stories as vertical slices. We have been
                                > emphasizing these two ideas over the last three months, and we have
                                > seen a calming of our velocity fluctuations.

                                Yeah, we went through exactly the same problem a couple of years ago.
                                It's played a role in our recent problems, but they've also had other
                                causes: a team merger with legacy code played a role (it's amazing how
                                long it can take to get out from under 25 red bars!); and we didn't
                                have real customers for a while, and were hence fooling ourselves
                                about certain issues.

                                Fortunately, there are signs of improvement on both the recent fronts
                                (if you're in the market for a honking big video server, go to
                                <http://www.sun.com/servers/networking/streamingsystem/>), as well as
                                on the small vertical slice issue that you mention, and our velocity
                                this month has been much smoother than in the past. So I'm
                                optimistic.

                                David Carlton
                                carlton@...
                              • Adam Sroka
                                ... This is the approach that Mike Cohn, who has devoted a lot of energy to this topic, advocates. He is more of a Scrum guy than an XP guy, but his
                                Message 15 of 25 , May 2, 2007
                                • 0 Attachment
                                  On 5/2/07, Ron Jeffries <ronjeffries@...> wrote:
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                  > Hello, Jeff. On Wednesday, May 2, 2007, at 4:50:13 PM, you wrote:
                                  >
                                  > > Quoting Ron Jeffries <ronjeffries@...>:
                                  > >>> Hm. Are you suggesting that we dispense with the concept of "velocity"
                                  > >>> completely?
                                  > >>
                                  > >> No.
                                  >
                                  > > Hm, ok thanks. Are you suggesting that we dispense with the concept of
                                  > > velocity for purposes of establishing a limit to commitment for an
                                  > > iteration?
                                  >
                                  > I think it's worth considering. Velocity (i.e. number of stories
                                  > done) is probably useful for predicting releases and for deciding
                                  > how to manage scope.
                                  >

                                  This is the approach that Mike Cohn, who has devoted a lot of energy
                                  to this topic, advocates. He is more of a Scrum guy than an XP guy,
                                  but his information is valuable. I attended one of his "Agile
                                  Estimating and Planning" courses in Santa Clara, CA last year and
                                  found it quite informative.

                                  Specifically, Mike advocates using an average, most recent, and lowest
                                  historical velocity to establish a range. He then uses this range to
                                  estimate how many stories will likely be done by a certain date,
                                  and/or when a particular collection of stories will be complete. This
                                  is used only for "big picture" and release planning. What stories will
                                  be attempted in an iteration is purely a function of what the team
                                  agrees to.

                                  It's probably worthwhile to take a look at his book:
                                  http://www.amazon.com/Agile-Estimating-Planning-Robert-Martin/dp/0131479415
                                • Rob Park
                                  For what it s worth, we work from an 8w rolling average. It s a very consistent number. The final iteration meeting adjustment tends to be whether to round
                                  Message 16 of 25 , May 2, 2007
                                  • 0 Attachment
                                    For what it's worth, we work from an 8w rolling average. It's a very
                                    consistent number. The final iteration meeting adjustment tends to be
                                    whether to round up or down.



                                    What we don't like about the literal yesterday's weather, is if the 8w
                                    average is 12, but last week we had major road blocks and achieved 5, 5
                                    makes no sense for next week. Similarly, if some things were easier than
                                    expected and we achieve 19, I don't want to commit to that.



                                    Possibly, with experience you really don't need to measure the average,
                                    because if you see 11, 10, 14, 12, 5, 12, 11, 12, you can make an educated
                                    guess at 11 or 12 without the actual average. I just think it's an easy
                                    number to calculate that it doesn't hurt.



                                    We also don't worry about unplanned absences, but even for planned ones, we
                                    never adjust the rounded average (up or down) more than +/- 1.



                                    rob.



                                    From: extremeprogramming@yahoogroups.com
                                    [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Jeff Langr
                                    Sent: Wednesday, May 02, 2007 2:19 PM
                                    To: extremeprogramming@yahoogroups.com
                                    Subject: Re: [XP] average velocity?



                                    Greetings Gary,

                                    Quoting Gary Brown <glbrown@... <mailto:glbrown%40inebraska.com>
                                    >:
                                    > We use each team's rolling three week average velocity to set their
                                    > expected velocity for planning purposes. We do adjust for planned
                                    > absences, like training, conferences, and vacation. We don't adjust
                                    > for unplanned absences that happen mid-iteration. In an organization
                                    > of our size, a few people are always missing, so that lost velocity
                                    > washes out in the rolling average.

                                    Thanks for the response! I agree with not worrying about one-day or
                                    unplanned absences. Sounds good. I haven't seen the 3-week average used.

                                    Jeff
                                    http://langrsoft.com/agileJava





                                    [Non-text portions of this message have been removed]
                                  • Rob Park
                                    We use the 8w avg for that too; to track where we are WRT plan. rob. From: extremeprogramming@yahoogroups.com [mailto:extremeprogramming@yahoogroups.com] On
                                    Message 17 of 25 , May 2, 2007
                                    • 0 Attachment
                                      We use the 8w avg for that too; to track where we are WRT plan.



                                      rob.



                                      From: extremeprogramming@yahoogroups.com
                                      [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Ron Jeffries
                                      Sent: Wednesday, May 02, 2007 2:57 PM
                                      To: extremeprogramming@yahoogroups.com
                                      Subject: Re: [XP] average velocity?



                                      Hello, Jeff. On Wednesday, May 2, 2007, at 4:50:13 PM, you wrote:

                                      > Quoting Ron Jeffries <ronjeffries@...
                                      <mailto:ronjeffries%40XProgramming.com> >:
                                      >>> Hm. Are you suggesting that we dispense with the concept of "velocity"
                                      >>> completely?
                                      >>
                                      >> No.

                                      > Hm, ok thanks. Are you suggesting that we dispense with the concept of
                                      > velocity for purposes of establishing a limit to commitment for an
                                      > iteration?

                                      I think it's worth considering. Velocity (i.e. number of stories
                                      done) is probably useful for predicting releases and for deciding
                                      how to manage scope.

                                      Ron Jeffries
                                      www.XProgramming.com
                                      It is not because things are difficult that we do not dare,
                                      it is because we do not dare that they are difficult. --Seneca





                                      [Non-text portions of this message have been removed]
                                    • Rob Park
                                      Do you have any variance numbers you can share? What was it then and now? Thanks. rob. From: extremeprogramming@yahoogroups.com
                                      Message 18 of 25 , May 2, 2007
                                      • 0 Attachment
                                        Do you have any variance numbers you can share?

                                        What was it then and now?



                                        Thanks.



                                        rob.



                                        From: extremeprogramming@yahoogroups.com
                                        [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Gary Brown
                                        Sent: Wednesday, May 02, 2007 3:46 PM
                                        To: extremeprogramming@yahoogroups.com
                                        Subject: Re: [XP] average velocity?



                                        Quoting David Carlton <carlton@... <mailto:carlton%40bactrian.org>
                                        >:

                                        > On Wed, 2 May 2007 16:56:49 -0400, Ron Jeffries
                                        > <ronjeffries@... <mailto:ronjeffries%40XProgramming.com> >
                                        said:
                                        >> Hello, Jeff. On Wednesday, May 2, 2007, at 4:50:13 PM, you wrote:
                                        >
                                        >>> Hm, ok thanks. Are you suggesting that we dispense with the concept of
                                        >>> velocity for purposes of establishing a limit to commitment for an
                                        >>> iteration?
                                        >
                                        >> I think it's worth considering. Velocity (i.e. number of stories
                                        >> done) is probably useful for predicting releases and for deciding
                                        >> how to manage scope.
                                        >
                                        > I don't like velocity as a tool for commitment because, among other
                                        > things, velocity is an average: you should be embarrassed if you don't
                                        > meet your commitments, while you should expect to be below average
                                        > half the time.
                                        >
                                        > It's not clear to me in what circumstances you need commitments to
                                        > delivering specific features during an iteration. (As opposed to
                                        > committing to do your best, knowing that sometimes you'll overdeliver
                                        > and sometimes you'll underdeliver.) If I were asked to do so, I
                                        > imagine that I'd commit to something closer to half the velocity than
                                        > the full velocity. Doubtless we're less consistent than is ideal, but
                                        > everybody has some variability.
                                        >
                                        > This is all related to something I'm dealing with at work right now:
                                        > just what roadmap promises should we make to our external customers
                                        > over the next N months?
                                        >
                                        > David Carlton

                                        In my organization, the problem with variance in velocity is mostly
                                        (~80%) due to large stories (greater than 4 units in our case) and our
                                        failure to write our stories as vertical slices. We have been
                                        emphasizing these two ideas over the last three months, and we have
                                        seen a calming of our velocity fluctuations.

                                        GB.





                                        [Non-text portions of this message have been removed]
                                      • Rob Park
                                        I track something very similar (and taken from Mike Cohn s book). I have a line graph that shows how our actual velocity hovers around / near our 8w average
                                        Message 19 of 25 , May 2, 2007
                                        • 0 Attachment
                                          I track something very similar (and taken from Mike Cohn's book).

                                          I have a line graph that shows how our actual velocity hovers around / near
                                          our 8w average and rarely dips below the average of the worst 3 of the last
                                          8 velocities.



                                          rob.



                                          From: extremeprogramming@yahoogroups.com
                                          [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Adam Sroka
                                          Sent: Wednesday, May 02, 2007 5:48 PM
                                          To: extremeprogramming@yahoogroups.com
                                          Subject: Re: [XP] average velocity?



                                          On 5/2/07, Ron Jeffries <ronjeffries@...
                                          <mailto:ronjeffries%40xprogramming.com> > wrote:
                                          >
                                          >
                                          >
                                          >
                                          >
                                          >
                                          > Hello, Jeff. On Wednesday, May 2, 2007, at 4:50:13 PM, you wrote:
                                          >
                                          > > Quoting Ron Jeffries <ronjeffries@...
                                          <mailto:ronjeffries%40XProgramming.com> >:
                                          > >>> Hm. Are you suggesting that we dispense with the concept of "velocity"
                                          > >>> completely?
                                          > >>
                                          > >> No.
                                          >
                                          > > Hm, ok thanks. Are you suggesting that we dispense with the concept of
                                          > > velocity for purposes of establishing a limit to commitment for an
                                          > > iteration?
                                          >
                                          > I think it's worth considering. Velocity (i.e. number of stories
                                          > done) is probably useful for predicting releases and for deciding
                                          > how to manage scope.
                                          >

                                          This is the approach that Mike Cohn, who has devoted a lot of energy
                                          to this topic, advocates. He is more of a Scrum guy than an XP guy,
                                          but his information is valuable. I attended one of his "Agile
                                          Estimating and Planning" courses in Santa Clara, CA last year and
                                          found it quite informative.

                                          Specifically, Mike advocates using an average, most recent, and lowest
                                          historical velocity to establish a range. He then uses this range to
                                          estimate how many stories will likely be done by a certain date,
                                          and/or when a particular collection of stories will be complete. This
                                          is used only for "big picture" and release planning. What stories will
                                          be attempted in an iteration is purely a function of what the team
                                          agrees to.

                                          It's probably worthwhile to take a look at his book:
                                          http://www.amazon.com/Agile-Estimating-Planning-Robert-Martin/dp/0131479415





                                          [Non-text portions of this message have been removed]
                                        • William Pietri
                                          ... 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
                                          Message 20 of 25 , May 2, 2007
                                          • 0 Attachment
                                            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

                                            --
                                            William Pietri - william@... - +1-415-643-1024
                                            Agile consulting, coaching, and development: http://www.scissor.com/
                                            A startup, done XP-style: http://www.sidereel.com/
                                          • Gary Brown
                                            ... Worst case was +/- 100%, now we re at +/- 30%, heading for +/- 10%. GB.
                                            Message 21 of 25 , May 3, 2007
                                            • 0 Attachment
                                              Quoting Rob Park <rpark68@...>:

                                              > Do you have any variance numbers you can share?
                                              >
                                              > What was it then and now?

                                              Worst case was +/- 100%, now we're at +/- 30%, heading for +/- 10%.

                                              GB.
                                            • 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 22 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.

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