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

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

Expand Messages
  • lidingshan
    Pascal Thivent wrote: The velocity is the amount of points the team can take per sprint. Giving this, applying a drag factor that lowers the
    Message 1 of 19 , Mar 31, 2008
    • 0 Attachment

      "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
      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 2 of 19 , Apr 1, 2008
      • 0 Attachment
        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 3 of 19 , Apr 2, 2008
        • 0 Attachment
          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 4 of 19 , Apr 2, 2008
          • 0 Attachment
            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 5 of 19 , Apr 2, 2008
            • 0 Attachment
              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 6 of 19 , Apr 3, 2008
              • 0 Attachment
                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 7 of 19 , Apr 3, 2008
                • 0 Attachment
                  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 8 of 19 , Apr 3, 2008
                  • 0 Attachment
                    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 9 of 19 , Apr 4, 2008
                    • 0 Attachment
                      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 10 of 19 , Apr 7, 2008
                      • 0 Attachment
                        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 11 of 19 , Apr 7, 2008
                        • 0 Attachment
                          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 12 of 19 , Apr 7, 2008
                          • 0 Attachment
                            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 13 of 19 , Apr 7, 2008
                            • 0 Attachment
                              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 14 of 19 , Apr 7, 2008
                              • 0 Attachment
                                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 15 of 19 , Apr 7, 2008
                                • 0 Attachment
                                  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.