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

Re: [scrumdevelopment] Re: What's the meaning of "Adjusted Planning Velocity"?

Expand Messages
  • Pascal Thivent
    Actually, i m not sure how this tool should be used: for the velocity of the first sprint, if conditions change, if a new team is introduced... I remember some
    Message 1 of 19 , Apr 1, 2008
      Actually, i'm not sure how this tool should be used: for the velocity
      of the first sprint, if conditions change, if a new team is
      introduced...

      I remember some slides in the CSM course talking about "Adjusted
      Estimate" which is calculated by applying a drag factor to the
      original estimate with a similar approach to the one you're
      mentioning.

      Adjusted estimate = estimate * (1 + drag factor) where the drag factor
      varies from 0.8 to 0 and depends on Time Together, Knowledge of
      Technology and Knowledge of Domain
      Adjusted estimate = estimate * 0.6 if teams are collocated
      Adjusted estimate = estimate * 1.4 if more than one team

      I may be missing something but I don't really see the point of
      applying a drag factor (on estimates or on the velocity) when using
      story points. This drag factor is already included in the velocity and
      the velocity will increase as the condition get better. This would
      make more sense with "Team Days" (or Ideal Team Days) and a fixed
      "velocity" equal to the number of days in a sprint.

      0On Tue, Apr 1, 2008 at 7:21 AM, lidingshan <lidingshan@...> wrote:
      >
      >
      >
      >
      >
      > "Pascal Thivent" <pascal@...> wrote:
      >
      > The velocity is the amount of points the team can take per sprint.
      > Giving this, applying a drag factor that lowers the velocity when
      > conditions are worth looks logical to me.
      >
      > Let's say the planning velocity is 100 but the team lacks of domain
      > knowledge (very low). The adjusted planning velocity is 60. The team
      > should take items for 60 points only.
      >
      > Do you mean that, when team make the estimation and pick up items totally
      > 100 points, then consider the adjusted velocity, then the team needs to move
      > out total 40 points items from the sprint planning scope?
      >
      >
      >
      >
      >



      --
      Pascal Thivent
    • Nicholas Cancelliere
      I m not sure where/why you heard about some velocity drag factor equation in a CSM course. I never was taught that. The whole idea seems like funny math to
      Message 2 of 19 , Apr 2, 2008
        I'm not sure where/why you heard about some velocity drag factor equation in a CSM course.  I never was taught that.

        The whole idea seems like funny math to me.  For example - how do you quantify the lack of domain knowledge to be .3 or .6?  Or time together - what's that mean?  Is that drinking beers at the pub, working together, etc.

        I think this equation help draw awareness to the idea that things like:  the team's domain knowledge, their evolution as a team (forming, storming, norming, performing), and colocation, etc.  all play into the velocity.  I do not know about the whole idea of "adjusted velocity," though.  If the team can take on only 40 pts, rather than 100 pts, their velocity is 40. 

        I think the idea of saying "Well if you guys were worth your salt you should be able to plan 100 pts, but because you don't have enough togetherness and your all dumb, I only expect you to do 40."  I think that'd would only be a morale killer for a team.  Why not instead simply focus on what the team can do -- which is what you defined velocity as.  All the "drag factors" are already built-in, you don't need to compensate further.  Don't confuse velocity with productivity (which is what it's feeling like you are doing here with the "planning velocity").

        The velocity is the velocity... if the Product Owner wants the team to do more then they need to understand what's holding up the team.

        Nicholas



        On Tue, Apr 1, 2008 at 6:03 PM, Pascal Thivent <pascal@...> wrote:
        Actually, i'm not sure how this tool should be used: for the velocity
        of the first sprint, if conditions change, if a new team is
        introduced...

        I remember some slides in the CSM course talking about "Adjusted
        Estimate" which is calculated by applying a drag factor to the
        original estimate with a similar approach to the one you're
        mentioning.

        Adjusted estimate = estimate * (1 + drag factor) where the drag factor
        varies from 0.8 to 0 and depends on Time Together, Knowledge of
        Technology and Knowledge of Domain
        Adjusted estimate = estimate * 0.6 if teams are collocated
        Adjusted estimate = estimate * 1.4 if more than one team

        I may be missing something but I don't really see the point of
        applying a drag factor (on estimates or on the velocity) when using
        story points. This drag factor is already included in the velocity and
        the velocity will increase as the condition get better. This would
        make more sense with "Team Days" (or Ideal Team Days) and a fixed
        "velocity" equal to the number of days in a sprint.

        0On Tue, Apr 1, 2008 at 7:21 AM, lidingshan <lidingshan@...> wrote:
        >
        >
        >
        >
        >
        > "Pascal Thivent" <pascal@...> wrote:
        >
        >  The velocity is the amount of points the team can take per sprint.
        >  Giving this, applying a drag factor that lowers the velocity when
        >  conditions are worth looks logical to me.
        >
        >  Let's say the planning velocity is 100 but the team lacks of domain
        >  knowledge (very low). The adjusted planning velocity is 60. The team
        >  should take items for 60 points only.
        >
        > Do you mean that, when team make the estimation and pick up items totally
        > 100 points, then consider the adjusted velocity, then the team needs to move
        > out total 40 points items from the sprint planning scope?
        >
        >
        >
        >
        >



        --
        Pascal Thivent

        ------------------------------------

        To Post a message, send it to:   scrumdevelopment@...
        To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

        <*> To visit your group on the web, go to:
           http://groups.yahoo.com/group/scrumdevelopment/

        <*> Your email settings:
           Individual Email | Traditional

        <*> To change settings online go to:
           http://groups.yahoo.com/group/scrumdevelopment/join
           (Yahoo! ID required)

        <*> To change settings via email:
           mailto:scrumdevelopment-digest@yahoogroups.com
           mailto:scrumdevelopment-fullfeatured@yahoogroups.com

        <*> To unsubscribe from this group, send an email to:
           scrumdevelopment-unsubscribe@yahoogroups.com

        <*> Your use of Yahoo! Groups is subject to:
           http://docs.yahoo.com/info/terms/




        --
        Nicholas Cancelliere - Austin, TX
        CSM/CSP and Rails Developer

        "Try not to become a man of success but rather to become a man of value." --Albert Einstein
      • Pascal Thivent
        Well, I m sure as I have the paper version on my desk right now : there are some slides about drag factor. Having reread them, I confirm this drag factor was
        Message 3 of 19 , Apr 2, 2008
          Well, I'm sure as I have the paper version on my desk right now :
          there are some slides about drag factor.

          Having reread them, I confirm this drag factor was applied on
          estimates in *ITD* and that the amount of work to take was based on
          the team *capacity* in ITD / sprint, not a velocity in story points.

          Check this sample course (http://www.scrumalliance.org/resources/36),
          p.37 to 45.

          Using story points for estimates has not always been the case and
          people did use Ideal days or Ideal Team Days earlier. With ITD, I can
          see the need for a drag factor and it juste makes the whole thing very
          similar to SP and velocity. It's just more complicated, less
          accurate... and I guess that's why we prefer story points today.

          Anyhow, as I wrote it, I don't don't see the point of a drag when
          using story points and velocity neither. I was just replying to the
          original question.

          Cheers,

          On Wed, Apr 2, 2008 at 7:34 PM, Nicholas Cancelliere
          <nickaustin74@...> wrote:
          >
          >
          >
          >
          > I'm not sure where/why you heard about some velocity drag factor equation in
          > a CSM course. I never was taught that.
          >
          > The whole idea seems like funny math to me. For example - how do you
          > quantify the lack of domain knowledge to be .3 or .6? Or time together -
          > what's that mean? Is that drinking beers at the pub, working together, etc.
          >
          > I think this equation help draw awareness to the idea that things like: the
          > team's domain knowledge, their evolution as a team (forming, storming,
          > norming, performing), and colocation, etc. all play into the velocity. I
          > do not know about the whole idea of "adjusted velocity," though. If the
          > team can take on only 40 pts, rather than 100 pts, their velocity is 40.
          >
          > I think the idea of saying "Well if you guys were worth your salt you should
          > be able to plan 100 pts, but because you don't have enough togetherness and
          > your all dumb, I only expect you to do 40." I think that'd would only be a
          > morale killer for a team. Why not instead simply focus on what the team can
          > do -- which is what you defined velocity as. All the "drag factors" are
          > already built-in, you don't need to compensate further. Don't confuse
          > velocity with productivity (which is what it's feeling like you are doing
          > here with the "planning velocity").
          >
          > The velocity is the velocity... if the Product Owner wants the team to do
          > more then they need to understand what's holding up the team.
          >
          > Nicholas
          >
          >
          >
          >
          >
          > On Tue, Apr 1, 2008 at 6:03 PM, Pascal Thivent <pascal@...> wrote:
          > >
          > >
          > >
          > > Actually, i'm not sure how this tool should be used: for the velocity
          > > of the first sprint, if conditions change, if a new team is
          > > introduced...
          > >
          > > I remember some slides in the CSM course talking about "Adjusted
          > > Estimate" which is calculated by applying a drag factor to the
          > > original estimate with a similar approach to the one you're
          > > mentioning.
          > >
          > > Adjusted estimate = estimate * (1 + drag factor) where the drag factor
          > > varies from 0.8 to 0 and depends on Time Together, Knowledge of
          > > Technology and Knowledge of Domain
          > > Adjusted estimate = estimate * 0.6 if teams are collocated
          > > Adjusted estimate = estimate * 1.4 if more than one team
          > >
          > > I may be missing something but I don't really see the point of
          > > applying a drag factor (on estimates or on the velocity) when using
          > > story points. This drag factor is already included in the velocity and
          > > the velocity will increase as the condition get better. This would
          > > make more sense with "Team Days" (or Ideal Team Days) and a fixed
          > > "velocity" equal to the number of days in a sprint.
          > >
          > >
          > > 0On Tue, Apr 1, 2008 at 7:21 AM, lidingshan <lidingshan@...> wrote:
          > > >
          > > >
          > > >
          > > >
          > > >
          > > > "Pascal Thivent" <pascal@...> wrote:
          > > >
          > > > The velocity is the amount of points the team can take per sprint.
          > > > Giving this, applying a drag factor that lowers the velocity when
          > > > conditions are worth looks logical to me.
          > > >
          > > > Let's say the planning velocity is 100 but the team lacks of domain
          > > > knowledge (very low). The adjusted planning velocity is 60. The team
          > > > should take items for 60 points only.
          > > >
          > > > Do you mean that, when team make the estimation and pick up items
          > totally
          > > > 100 points, then consider the adjusted velocity, then the team needs to
          > move
          > > > out total 40 points items from the sprint planning scope?
          > > >
          > > >
          > > >
          > > >
          > > >
          > >
          > >
          > >
          > > --
          > > Pascal Thivent
          > >
          > > ------------------------------------
          > >
          > >
          > >
          > > To Post a message, send it to: scrumdevelopment@...
          > >
          > > To Unsubscribe, send a blank message to:
          > scrumdevelopment-unsubscribe@...! Groups Links
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          >
          >
          >
          > --
          > Nicholas Cancelliere - Austin, TX
          > CSM/CSP and Rails Developer
          >
          > "Try not to become a man of success but rather to become a man of value."
          > --Albert Einstein
          >
          >



          --
          Pascal
        • Peter Hundermark
          Hi, The whole thing sounds like a throwback to defined methods. In fact, it bears a strong resemblance to COCOMO II. Of course it is appealing to think we
          Message 4 of 19 , Apr 2, 2008
            Hi,

            The whole thing sounds like a throwback to defined methods. In fact, it
            bears a strong resemblance to COCOMO II. Of course it is appealing to
            think we could calibrate our velocity model with this neat set of
            factors and values. But we're dealing with complexity here. Which is why
            we use an empirical framework.

            Yes, we expect the team to produce less DONE software when:
            * They are not collocated
            * They are a new team
            * The domain is novel
            * The tools/technology are unfamiliar
            * They are unused to collaboration / self-organisation (Scrum) - I added
            this one to your list!

            But, as George says, using "yesterday's weather", or as I recommend, a
            rolling average of the last 3 sprints, the team will quickly establish a
            reasonable velocity estimate.

            And I always try to emphasize that velocity only exists to create (and
            update) a credible release plan / product burndown. The only important
            measure of progress for the team is shippable business functionality.

            Regards,

            Peter
            CSC

            --- In scrumdevelopment@yahoogroups.com, "lidingshan" <lidingshan@...>
            wrote:
            >
            > I read a document mentioned that, when a Scrum team try to do the
            > estimation, they need to use the "Adjusted Planning Velocity" - The
            > planning velocity multiply several drag factors. The formula is:
            >
            > Adjusted Planning Velocity (units are Points/Sprint)
            > = Planning Velocity x DP x DF x DT x DD
            >
            > The values of DP, DF, DT and DD are
            >
            > Proximity(DP)
            >
            > * Multiple Time Zones: 0.8
            > * Same Office Building: 1.0
            > * Radical Colocation: 1.6
            > Time Together(DF)
            >
            > * <3 months: 0.6
            > * 3 to 12 months: 0.8
            > * >12 months: 1.0
            > Knowledge of Technology (DT)
            >
            > * Low: 0.6
            > * Medium: 0.8
            > * High: 1.0
            > Knowledge of Domain (DD)
            >
            > * Low: 0.6
            > * Medium: 0.8
            > * High: 1.0
            > The question is, why the drag factor value is smaller as the condition
            > is worth. For example, when the "Knowledge of Technology" is low, the
            > factor value is 0.6. That means the value of Adjusted Planning
            Velocity
            > is smaller than the original Planning Velocity. It doesn't make sense
            to
            > me because based on my understanding, if the condition is worth, the
            > adjusted velocity should be larger because the team needs more effort
            to
            > complete it. I am not quite understand what this adjusted velocity
            mean
            > and how to use it. Please provide your suggestions and thanks a lot.
            >
          • Mark Levison
            I think its typically used when you re trying to establish the initial capacity for a team - that have not used Scrum before. Once you ve a few sprints and
            Message 5 of 19 , Apr 3, 2008
              I think its typically used when you're trying to establish the initial capacity for a team - that have not used Scrum before.

              Once you've a few sprints and therefore some history behind you Yesterday's weather is more useful than an emperical calculation.

              Mark CS?
              ----------------------------------------------------------------------
              Blog: http://www.notesfromatooluser.com/
              One Year of Scrum: Lessons Learned
              http://www.notesfromatooluser.com/2007/10/one-year-of-scr.html
              Aperture vs. Lightroom - best comparisons
              http://www.notesfromatooluser.com/2007/02/aperture_vs_lig.html
              Customer Retention Department - Vonage Customer Service Sucks
              http://www.notesfromatooluser.com/2007/06/customer_retent.html
            • James S. Fosdick, PMP, CSP
              There are a number of issues in play here. First off Scrum is so simple and Agile is so lightweight that people are often tempted to improve it with more
              Message 6 of 19 , Apr 3, 2008
                There are a number of issues in play here. First off Scrum is so
                simple and Agile is so lightweight that people are often tempted to
                "improve" it with more complex innovations. Virtually all these
                mutations are, in my experience, deleterious. Velocity is a simple
                empirical observation that is retrospective and helps with longer
                range planning. Innovating on that with additional concepts is
                unnecessary. Velocity is what it is. Adding layers of complexity adds
                no value. For example of you say your velocity is X you are saying
                that you observed the team completing X in a given sprint. You can
                predict that you will probably deliver X in subsequent sprints. Adding
                a multiplier just adds more math without giving you additional
                information. People also seem to think that adding to the complexity
                of a mathematical equation adds to it's precision. In that case of
                velocity calculations that simply isn't the case.
              • Mark Levison
                I m sorry James - I think your wrong. I don t have time to go through the slide decks from the course but I really do think that this was involved in answering
                Message 7 of 19 , Apr 3, 2008
                  I'm sorry James - I think your wrong. I don't have time to go through the slide decks from the course but I really do think that this was involved in answering the problem of estimating initial capacity so the team has some clue as to how many stories they can safely commit to.

                  Of course no someone will cite line and verse proving me a fool.

                  Mark
                  ----------------------------------------------------------------------
                  Blog: http://www.notesfromatooluser.com/
                  One Year of Scrum: Lessons Learned
                  http://www.notesfromatooluser.com/2007/10/one-year-of-scr.html
                  Aperture vs. Lightroom - best comparisons
                  http://www.notesfromatooluser.com/2007/02/aperture_vs_lig.html
                  Customer Retention Department - Vonage Customer Service Sucks
                  http://www.notesfromatooluser.com/2007/06/customer_retent.html
                • Peter Hundermark
                  Mark, For me this would be the worst possible place to use this. A new team establishes its capacity by committing to the backlog items one by one until they
                  Message 8 of 19 , Apr 4, 2008
                    Mark,

                    For me this would be the worst possible place to use this. A new team
                    establishes its capacity by committing to the backlog items one by one
                    until they feel unable to take on more. The fidelity is low, but so
                    what? No formulaic approach such as described in this post will yield a
                    more accurate result, but the danger is that it may *appear* to.

                    Comments?

                    Peter
                    CSC



                    --- In scrumdevelopment@yahoogroups.com, "Mark Levison" <mlevison@...>
                    wrote:
                    >
                    > I think its typically used when you're trying to establish the initial
                    > capacity for a team - that have not used Scrum before.
                    >
                    > Once you've a few sprints and therefore some history behind you
                    Yesterday's
                    > weather is more useful than an emperical calculation.
                    >
                    > Mark CS?
                    > ----------------------------------------------------------------------
                    > Blog: http://www.notesfromatooluser.com/
                    > One Year of Scrum: Lessons Learned
                    > http://www.notesfromatooluser.com/2007/10/one-year-of-scr.html
                    > Aperture vs. Lightroom - best comparisons
                    > http://www.notesfromatooluser.com/2007/02/aperture_vs_lig.html
                    > Customer Retention Department - Vonage Customer Service Sucks
                    > http://www.notesfromatooluser.com/2007/06/customer_retent.html
                    >
                  • Mark Levison
                    Peter, I m not saying I ve ever used this approach. I m just remembering how it was framed in my CSM course nearly 18 mths ago. Honestly I don t see a huge
                    Message 9 of 19 , Apr 7, 2008
                      Peter, I'm not saying I've ever used this approach. I'm just remembering how it was framed in my CSM course nearly 18 mths ago. Honestly I don't see a huge problem if it helps the team limit what they try to take on in the first few iterations.

                      Every team I've seen over commits for the first little while. My current team has just grown by four team members and all of sudden we're taking on way too much and making a mess of it. In fact some team members are prepared to compromise quality, to get stories "done". As a result I have to act as a brake, reminding them of the importance of quality. If we'd had a better estimate of our initial capacity we might be better off now.

                      Mark
                      ----------------------------------------------------------------------
                      Blog: http://www.notesfromatooluser.com/
                      One Year of Scrum: Lessons Learned
                      http://www.notesfromatooluser.com/2007/10/one-year-of-scr.html
                      Aperture vs. Lightroom - best comparisons
                      http://www.notesfromatooluser.com/2007/02/aperture_vs_lig.html
                      Customer Retention Department - Vonage Customer Service Sucks
                      http://www.notesfromatooluser.com/2007/06/customer_retent.html
                    • James S. Fosdick, PMP, CSP
                      I don t deny that that s what it s for. My argument is that it is a flawed strategy. In my opinion velocity based planning in sprint 1 is very dangerous. It
                      Message 10 of 19 , Apr 7, 2008
                        I don't deny that that's what it's for. My argument is that it is a
                        flawed strategy. In my opinion velocity based planning in sprint 1 is
                        very dangerous. It takes several sprints to calibrate your velocity
                        metrics so trying to base a committment on them (before you have them)
                        doesn't make sense and is certainly not improved by adding a bunch of
                        cruft. Rather the team should decompose backlog items until their
                        available time is filled up and than back off one or two items.
                        Pretending that we have a "scientific" way of estimating initial
                        velocity by adding a bunch of multiplication factors feels very
                        "waterfallish" to me. In any case it is definitely 100% voodoo which
                        is something agile tries to get away from.

                        Jimi

                        --- In scrumdevelopment@yahoogroups.com, "Mark Levison" <mlevison@...>
                        wrote:
                        >
                        > I'm sorry James - I think your wrong. I don't have time to go
                        through the
                        > slide decks from the course but I really do think that this was
                        involved in
                        > answering the problem of estimating initial capacity so the team has
                        some
                        > clue as to how many stories they can safely commit to.
                        >
                        > Of course no someone will cite line and verse proving me a fool.
                        >
                        > Mark
                        > ----------------------------------------------------------------------
                        > Blog: http://www.notesfromatooluser.com/
                        > One Year of Scrum: Lessons Learned
                        > http://www.notesfromatooluser.com/2007/10/one-year-of-scr.html
                        > Aperture vs. Lightroom - best comparisons
                        > http://www.notesfromatooluser.com/2007/02/aperture_vs_lig.html
                        > Customer Retention Department - Vonage Customer Service Sucks
                        > http://www.notesfromatooluser.com/2007/06/customer_retent.html
                        >
                      • James S. Fosdick, PMP, CSP
                        I don t deny that that s what it s for. My argument is that it is a flawed strategy. In my opinion velocity based planning in sprint 1 is very dangerous. It
                        Message 11 of 19 , Apr 7, 2008
                          I don't deny that that's what it's for. My argument is that it is a
                          flawed strategy. In my opinion velocity based planning in sprint 1 is
                          very dangerous. It takes several sprints to calibrate your velocity
                          metrics so trying to base a committment on them (before you have them)
                          doesn't make sense and is certainly not improved by adding a bunch of
                          cruft. Rather the team should decompose backlog items until their
                          available time is filled up and than back off one or two items.
                          Pretending that we have a "scientific" way of estimating initial
                          velocity by adding a bunch of multiplication factors feels very
                          "waterfallish" to me. In any case it is definitely 100% voodoo which
                          is something agile tries to get away from.

                          Jimi

                          --- In scrumdevelopment@yahoogroups.com, "Mark Levison" <mlevison@...>
                          wrote:
                          >
                          > I'm sorry James - I think your wrong. I don't have time to go
                          through the
                          > slide decks from the course but I really do think that this was
                          involved in
                        • woynam
                          I agree. Agile is based on honesty. I don t see anything wrong with saying Look, we re about to kick off our first sprint, with a new team, and a new process.
                          Message 12 of 19 , Apr 7, 2008
                            I agree. Agile is based on honesty. I don't see anything wrong with
                            saying "Look, we're about to kick off our first sprint, with a new
                            team, and a new process. Frankly, we simply do not *know* how much
                            we'll get done. Historically, a team knows the least at the beginning
                            of a project, regardless of the process used. We'll do our best to
                            estimate the features, but it's likely we'll be off. We'll have a much
                            better idea how much we can commit to at the end of the upcoming
                            iteration."

                            Trying to come up with a "scientific" basis for velocity at this point
                            in time is asking for trouble.

                            Mark

                            --- In scrumdevelopment@yahoogroups.com, "James S. Fosdick, PMP, CSP"
                            <jsfosdickcsp@...> wrote:
                            >
                            > I don't deny that that's what it's for. My argument is that it is a
                            > flawed strategy. In my opinion velocity based planning in sprint 1 is
                            > very dangerous. It takes several sprints to calibrate your velocity
                            > metrics so trying to base a committment on them (before you have them)
                            > doesn't make sense and is certainly not improved by adding a bunch of
                            > cruft. Rather the team should decompose backlog items until their
                            > available time is filled up and than back off one or two items.
                            > Pretending that we have a "scientific" way of estimating initial
                            > velocity by adding a bunch of multiplication factors feels very
                            > "waterfallish" to me. In any case it is definitely 100% voodoo which
                            > is something agile tries to get away from.
                            >
                            > Jimi
                            >
                            > --- In scrumdevelopment@yahoogroups.com, "Mark Levison" <mlevison@>
                            > wrote:
                            > >
                            > > I'm sorry James - I think your wrong. I don't have time to go
                            > through the
                            > > slide decks from the course but I really do think that this was
                            > involved in
                            > > answering the problem of estimating initial capacity so the team has
                            > some
                            > > clue as to how many stories they can safely commit to.
                            > >
                            > > Of course no someone will cite line and verse proving me a fool.
                            > >
                            > > Mark
                            > > ----------------------------------------------------------------------
                            > > Blog: http://www.notesfromatooluser.com/
                            > > One Year of Scrum: Lessons Learned
                            > > http://www.notesfromatooluser.com/2007/10/one-year-of-scr.html
                            > > Aperture vs. Lightroom - best comparisons
                            > > http://www.notesfromatooluser.com/2007/02/aperture_vs_lig.html
                            > > Customer Retention Department - Vonage Customer Service Sucks
                            > > http://www.notesfromatooluser.com/2007/06/customer_retent.html
                            > >
                            >
                          • Dan Rawsthorne
                            I agree with Jim. In fact, I like to use velocity only for release strategies, to look way into the future. For sprint planning I prefer commitment based
                            Message 13 of 19 , Apr 7, 2008
                              I agree with Jim. In fact, I like to use velocity only for release
                              strategies, to look way into the future. For sprint planning I prefer
                              commitment based planning, which causes the team to actually look at the
                              stories in front of them,

                              Dan Rawsthorne, PhD, CST
                              Senior Coach, Danube Technologies
                              dan@..., 425-269-8628



                              James S. Fosdick, PMP, CSP wrote:
                              >
                              > I don't deny that that's what it's for. My argument is that it is a
                              > flawed strategy. In my opinion velocity based planning in sprint 1 is
                              > very dangerous. It takes several sprints to calibrate your velocity
                              > metrics so trying to base a committment on them (before you have them)
                              > doesn't make sense and is certainly not improved by adding a bunch of
                              > cruft. Rather the team should decompose backlog items until their
                              > available time is filled up and than back off one or two items.
                              > Pretending that we have a "scientific" way of estimating initial
                              > velocity by adding a bunch of multiplication factors feels very
                              > "waterfallish" to me. In any case it is definitely 100% voodoo which
                              > is something agile tries to get away from.
                              >
                              > Jimi
                              >
                              > --- In scrumdevelopment@yahoogroups.com
                              > <mailto:scrumdevelopment%40yahoogroups.com>, "Mark Levison" <mlevison@...>
                              > wrote:
                              > >
                              > > I'm sorry James - I think your wrong. I don't have time to go
                              > through the
                              > > slide decks from the course but I really do think that this was
                              > involved in
                              > > answering the problem of estimating initial capacity so the team has
                              > some
                              > > clue as to how many stories they can safely commit to.
                              > >
                              > > Of course no someone will cite line and verse proving me a fool.
                              > >
                              > > Mark
                              > > ----------------------------------------------------------
                              > > Blog: http://www.notesfromatooluser.com/
                              > <http://www.notesfromatooluser.com/>
                              > > One Year of Scrum: Lessons Learned
                              > > http://www.notesfromatooluser.com/2007/10/one-year-of-scr.html
                              > <http://www.notesfromatooluser.com/2007/10/one-year-of-scr.html>
                              > > Aperture vs. Lightroom - best comparisons
                              > > http://www.notesfromatooluser.com/2007/02/aperture_vs_lig.html
                              > <http://www.notesfromatooluser.com/2007/02/aperture_vs_lig.html>
                              > > Customer Retention Department - Vonage Customer Service Sucks
                              > > http://www.notesfromatooluser.com/2007/06/customer_retent.html
                              > <http://www.notesfromatooluser.com/2007/06/customer_retent.html>
                              > >
                              >
                              >
                            • Nicholas Cancelliere
                              Velocity number to be used as a tool, it assumes all things being the same... So the team can look at it to tweak their commitments: Do we feel our pace
                              Message 14 of 19 , Apr 7, 2008
                                Velocity number to be used as a tool, it assumes "all things being the same..."   So the team can look at it to tweak their commitments:  Do we feel our pace is sustainable?  No - take on less work, yes - take on more work.  As a product owner you can use velocity to try and guess when features will be taken on by the development team.

                                Anything beyond this and you're starting to move away from empirical methods -- which I think Scrum is about.  Scrum is an empirical approach to project management, we go with what we know and what we've observed.  Crazy math computations to divine the future are not what Scrum is about.  (I still want to know how you quantify "togetherness" as a factor of 0.6 to 1!)

                                Change a team membership, change the technology stack, etc ... the velocity will change too.  There is no magic formula other than time and observation.

                                Nicholas


                                On Mon, Apr 7, 2008 at 2:12 PM, Dan Rawsthorne <dan.rawsthorne@...> wrote:
                                I agree with Jim. In fact, I like to use velocity only for release
                                strategies, to look way into the future. For sprint planning I prefer
                                commitment based planning, which causes the team to actually look at the
                                stories in front of them,

                                Dan Rawsthorne, PhD, CST
                                Senior Coach, Danube Technologies
                                dan@..., 425-269-8628



                                James S. Fosdick, PMP, CSP wrote:
                                >
                                > I don't deny that that's what it's for. My argument is that it is a
                                > flawed strategy. In my opinion velocity based planning in sprint 1 is
                                > very dangerous. It takes several sprints to calibrate your velocity
                                > metrics so trying to base a committment on them (before you have them)
                                > doesn't make sense and is certainly not improved by adding a bunch of
                                > cruft. Rather the team should decompose backlog items until their
                                > available time is filled up and than back off one or two items.
                                > Pretending that we have a "scientific" way of estimating initial
                                > velocity by adding a bunch of multiplication factors feels very
                                > "waterfallish" to me. In any case it is definitely 100% voodoo which
                                > is something agile tries to get away from.
                                >
                                > Jimi
                                >
                                > --- In scrumdevelopment@yahoogroups.com
                                > <mailto:scrumdevelopment%40yahoogroups.com>, "Mark Levison" <mlevison@...>
                                > wrote:
                                > >
                                > > I'm sorry James - I think your wrong. I don't have time to go
                                > through the
                                > > slide decks from the course but I really do think that this was
                                > involved in
                                > > answering the problem of estimating initial capacity so the team has
                                > some
                                > > clue as to how many stories they can safely commit to.
                                > >
                                > > Of course no someone will cite line and verse proving me a fool.
                                > >
                                > > Mark
                                > > ----------------------------------------------------------
                                > > Blog: http://www.notesfromatooluser.com/
                                > <http://www.notesfromatooluser.com/>
                                > > One Year of Scrum: Lessons Learned
                                > > http://www.notesfromatooluser.com/2007/10/one-year-of-scr.html
                                > <http://www.notesfromatooluser.com/2007/10/one-year-of-scr.html>
                                > > Aperture vs. Lightroom - best comparisons
                                > > http://www.notesfromatooluser.com/2007/02/aperture_vs_lig.html
                                > <http://www.notesfromatooluser.com/2007/02/aperture_vs_lig.html>
                                > > Customer Retention Department - Vonage Customer Service Sucks
                                > > http://www.notesfromatooluser.com/2007/06/customer_retent.html
                                > <http://www.notesfromatooluser.com/2007/06/customer_retent.html>
                                > >
                                >
                                >

                                ------------------------------------

                                To Post a message, send it to:   scrumdevelopment@...
                                To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

                                <*> To visit your group on the web, go to:
                                   http://groups.yahoo.com/group/scrumdevelopment/

                                <*> Your email settings:
                                   Individual Email | Traditional

                                <*> To change settings online go to:
                                   http://groups.yahoo.com/group/scrumdevelopment/join
                                   (Yahoo! ID required)

                                <*> To change settings via email:
                                   mailto:scrumdevelopment-digest@yahoogroups.com
                                   mailto:scrumdevelopment-fullfeatured@yahoogroups.com

                                <*> To unsubscribe from this group, send an email to:
                                   scrumdevelopment-unsubscribe@yahoogroups.com

                                <*> Your use of Yahoo! Groups is subject to:
                                   http://docs.yahoo.com/info/terms/




                                --
                                Nicholas Cancelliere - Austin, TX
                                CSM/CSP and Rails Developer

                                "Try not to become a man of success but rather to become a man of value." --Albert Einstein
                              Your message has been successfully submitted and would be delivered to recipients shortly.