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

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

Expand Messages
  • lidingshan
    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
    Message 1 of 19 , Mar 30, 2008
      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.
    • Jaideep Khanduja
      Lidingshan wrote - The question is, why the drag factor value is smaller as the condition is worth. For example, when the Knowledge of Technology is low,
      Message 2 of 19 , Mar 30, 2008

        Lidingshan wrote – “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. “

         

        When the “knowledge of Technology” is low the factor value is 0.6, which means the things are moving at a lower pace as compared to if the “knowledge of Technology” factor value was 1.0. That shows the downward swift in the Planning velocity.

        Confidentiality Notice:

        The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at admin@... immediately and destroy all the copies of this message and any attachments

      • Pascal Thivent
        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
        Message 3 of 19 , Mar 30, 2008
          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.


          On Mon, Mar 31, 2008 at 6:40 AM, 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.6Time Together(DF)
          >
          >
          > <3 months: 0.6
          > 3 to 12 months: 0.8
          > >12 months: 1.0Knowledge of Technology (DT)
          >
          >
          > Low: 0.6
          > Medium: 0.8
          > High: 1.0Knowledge of Domain (DD)
          >
          >
          > Low: 0.6
          > Medium: 0.8
          > High: 1.0The 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.
          >
          >



          --
          Pascal Thivent
        • George Dinwiddie
          ... [snip] ... Velocity is the amount of work accomplished. The harder it is, the less accomplished. ... I m not sure you need to use it at all. It could,
          Message 4 of 19 , Mar 31, 2008
            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.
            [snip]
            > 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.

            Velocity is the amount of work accomplished. The harder it is, the less
            accomplished.

            > I am not quite understand what this adjusted velocity mean
            > and how to use it. Please provide your suggestions and thanks a lot.

            I'm not sure you need to use it at all. It could, perhaps, be useful
            for estimating velocity at the start of the project. But after the
            first sprint, using the technique of "yesterday's weather" avoids any
            calculations.

            The technique "yesterday's weather" means to expect to accomplish about
            the same amount this sprint as you did the last sprint. Of course there
            will be variation from sprint to sprint, but for the most part, it is
            not possible to predict this accurately. If you can't be accurate,
            there's no point in trying to add extra precision.

            If you know there is a major difference, you might want to account for
            it. For example, if half the team is leaving, you might guess that
            you'll accomplish less than half your former velocity.

            Most of the time, however, it's just little things. And since little
            things happen all the time, they get reflected in the "yesterday's
            weather" number.

            - George

            --
            ----------------------------------------------------------------------
            * George Dinwiddie * http://blog.gdinwiddie.com
            Software Development http://www.idiacomputing.com
            Consultant and Coach http://www.agilemaryland.org
            ----------------------------------------------------------------------
          • 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 5 of 19 , Mar 31, 2008

              "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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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.