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

Re: [scrumdevelopment] Velocity - Estimate or Actuals?

Expand Messages
  • William Wake
    ... I use historical estimates (but I do try to get better estimates). I look at velocity as, what is the team s demonstrated ability to predict and deliver
    Message 1 of 19 , Aug 1 6:24 PM
    • 0 Attachment
      On 8/1/06, Nicholas Cancelliere <nicholas@...> wrote:
      > I've read that velocity is calculated using historical estimates
      > (what the team estimated and committed to) vs. the actuals a team
      > did. An example (condensed for easy math):
      >
      > 5 day iteration, three developers are expected to burn 5 hrs a day
      > (the other 3 hrs are slop/buffer for email, meetings, etc - last
      > day), there are 3 stories (for each developer).
      >
      > Story 1 - 20 hrs estimated - 22 actual
      > Story 2 - 20 hrs estimated - 38 actual
      > Story 3 - 20 hrs estimated - 18 actual
      >
      > Would you not then say the velocity as 78 (average of the 3 actuals,
      > 26 * 3), and maybe schedule 70-75 hrs next iteration, or is it just
      > 60. I am having a difficult time explaining this to our project
      > manager to understand why actuals don't equal velocity -- or should
      > they? In Mike Cohn's book it seems to indicate velocity is based on
      > historical estimates, not the actuals.

      I use historical estimates (but I do try to get better estimates). I
      look at velocity as, "what is the team's demonstrated ability to
      predict and deliver stories?"

      In the case at hand, it seems to me like you're talking about going
      exactly the wrong direction. You tried to schedule 60 hours work, but
      it ended up as 78 (~30% over the prediction). For you to actually
      schedule 60 hours work, it seems you should have planned ~45 hours.

      (In this case, it looks like 2 stories were close to their estimate,
      one was way over. I'd want to understand what happened there. Is it
      something that's going to affect a certain class of story?)

      What I'd do:
      - re-estimate the remaining stories in light of what I learned this time
      - estimate 60 as my velocity for next iteration.
      - deliver those 60 and expect/hope to ask for more stories (raising
      your velocity)

      (We expect to do more, as we believe our estimates are now more accurate.)

      I prefer to let velocity be a "trailing" indicator in this sense, as a
      measure of our *demonstrated* ability to deliver.


      --
      Bill Wake William.Wake@... www.xp123.com
    • Nicholas Cancelliere
      I think you hit it on the nose. I d guess that when the PM hears the word velocity she s naturally thinking in terms of speed and how much work the team is
      Message 2 of 19 , Aug 1 7:49 PM
      • 0 Attachment
        I think you hit it on the nose.  I'd guess that when the PM hears the word "velocity" she's naturally thinking in terms of speed and how much work the team is able to process.  The subtle difference is the idea of the team's ability to demonstrate predict and deliver stories.  I'll try to explain it in this way and see how that goes over. 

        The example was made up to demonstrate the point, but yeah if there was a 38 I'd want to know what went wrong there in the estimate.  



        On Aug 1, 2006, at 8:24 PM, William Wake wrote:

        On 8/1/06, Nicholas Cancelliere <nicholas@ozmox.com> wrote:
        > I've read that velocity is calculated using historical estimates
        > (what the team estimated and committed to) vs. the actuals a team
        > did. An example (condensed for easy math):
        >
        > 5 day iteration, three developers are expected to burn 5 hrs a day
        > (the other 3 hrs are slop/buffer for email, meetings, etc - last
        > day), there are 3 stories (for each developer).
        >
        > Story 1 - 20 hrs estimated - 22 actual
        > Story 2 - 20 hrs estimated - 38 actual
        > Story 3 - 20 hrs estimated - 18 actual
        >
        > Would you not then say the velocity as 78 (average of the 3 actuals,
        > 26 * 3), and maybe schedule 70-75 hrs next iteration, or is it just
        > 60. I am having a difficult time explaining this to our project
        > manager to understand why actuals don't equal velocity -- or should
        > they? In Mike Cohn's book it seems to indicate velocity is based on
        > historical estimates, not the actuals.

        I use historical estimates (but I do try to get better estimates). I
        look at velocity as, "what is the team's demonstrated ability to
        predict and deliver stories?"

        In the case at hand, it seems to me like you're talking about going
        exactly the wrong direction. You tried to schedule 60 hours work, but
        it ended up as 78 (~30% over the prediction). For you to actually
        schedule 60 hours work, it seems you should have planned ~45 hours.

        (In this case, it looks like 2 stories were close to their estimate,
        one was way over. I'd want to understand what happened there. Is it
        something that's going to affect a certain class of story?)

        What I'd do:
        - re-estimate the remaining stories in light of what I learned this time
        - estimate 60 as my velocity for next iteration.
        - deliver those 60 and expect/hope to ask for more stories (raising
        your velocity)

        (We expect to do more, as we believe our estimates are now more accurate.)

        I prefer to let velocity be a "trailing" indicator in this sense, as a
        measure of our *demonstrated* ability to deliver.

        --
        Bill Wake William.Wake@acm.org www.xp123.com


      • Keith Sader
        ... How accurate an estimate is needed? Is there a range of uncertainty that is allowed or is an estimate in this case a precise amount of hours(which seems
        Message 3 of 19 , Aug 1 9:07 PM
        • 0 Attachment
          On 8/1/06, Nicholas Cancelliere <nicholas@...> wrote:
          >
          > The example was made up to demonstrate the point, but yeah if there was a 38 I'd want to know what went wrong there in the estimate.
          >

          How accurate an estimate is needed? Is there a range of uncertainty
          that is allowed or is an estimate in this case a precise amount of
          hours(which seems to be an odd defintion of estimate)?

          If one was making a statisitical analysis there would be concern for
          multiple outlying points, but estimates do tend to 'range' depending
          upon the story and task in my experience.

          I.e. The team estimates that story A will have 5 tasks totally 30
          hours. It turns out during the work that it takes 8 tasks and 50
          hours. Was story A estimated poorly? What could one say went wrong
          if the story was implemented to the user's satisfaction?

          thanks,
          --
          Keith Sader
          ksader@...
          http://www.sader-family.org/roller/page/ksader
          (coming back)http://www.saderfamily.org/roller/page/ksader
        • Chris S. Sterling
          Even though this might be a bit off topic to start off with, I have found that using a more abstract version of estimating has been more useful for my projects
          Message 4 of 19 , Aug 1 9:23 PM
          • 0 Attachment
            Even though this might be a bit off topic to start off with, I have
            found that using a more abstract version of estimating has been more
            useful for my projects to determine a velocity. This abstraction
            started out with days of effort left, then moved to story points, and
            recently I have found that t-shirt sizing has been the most "accurate"
            for me. Accurate is quoted because estimates, as you have shown in
            your estimates vs. actuals example, are incorrect by nature of humans
            not being able to predict the future. By using more abstract
            estimating units managers, customers, and product owners are less
            likely to equate actuals and estimates based on time as predictable
            units for a velocity to be defined by. It will probably start a
            conversation such as "what are these points anyway?" but that is
            another thread on this list.

            When applying the t-shirt sizing method we usually use a doubling
            factor from XS to L as pointed out in the Mike Cohn book "Agile
            Estimating and Planning". It appears to be much easier for teams to
            make comparisons between stories than to define duration based
            estimations. For instance, here is a breakdown of the points to
            t-shirt size:

            XS - 1
            S - 3
            M - 6
            L - 12
            XL - ? (doesn't matter, too BIG)

            As you can see, XS does not keep with the doubling factor and I can't
            explain that very quickly so I will just leave it up to the
            imagination of how we got to the unit 1. Based on the points we can
            derive a velocity over the first few iterations with the team as an
            average or something close to that such as:

            Sprint 1 - 33 points completed
            Sprint 2 - 42 points completed
            Sprint 3 - 38 points completed

            Based on this information we may decide that our velocity is
            approximately 37 points and decide on how close to this point total
            that we should allow on the sprint backlog. There are definite
            possibilities of anomalies for an individual sprint but this doesn't
            usually mean the estimation and velocity planning was flawed. It is
            usually because there are more unknowns in the items that are
            prioritized high on the product backlog and making their way onto the
            sprint backlog.

            To make a long story short, I have found over my past 4-6 projects
            that velocity derived from estimates has been more useful than from
            any averages derived from actuals. In fact, I have usually not found
            use for tracking actuals at all unless we were trying to educate the
            customer on the state of their legacy codebase which we are now
            maintaining and what types of features take longer to work on.

            Chris Sterling
            SolutionsIQ
            www.SolutionsIQ.com <http://www.solutionsiq.com/>
            10785 Willows Road NE
            Redmond, WA 98052
            csterling@...

            ________________________________

            From: scrumdevelopment@yahoogroups.com on behalf of Nicholas
            Cancelliere
            Sent: Tue 8/1/2006 17:15
            To: scrumdevelopment@yahoogroups.com
            Subject: [scrumdevelopment] Velocity - Estimate or Actuals?




            I've read that velocity is calculated using historical estimates
            (what the team estimated and committed to) vs. the actuals a team
            did. An example (condensed for easy math):

            5 day iteration, three developers are expected to burn 5 hrs a day
            (the other 3 hrs are slop/buffer for email, meetings, etc - last
            day), there are 3 stories (for each developer).

            Story 1 - 20 hrs estimated - 22 actual
            Story 2 - 20 hrs estimated - 38 actual
            Story 3 - 20 hrs estimated - 18 actual

            Would you not then say the velocity as 78 (average of the 3 actuals,
            26 * 3), and maybe schedule 70-75 hrs next iteration, or is it just
            60. I am having a difficult time explaining this to our project
            manager to understand why actuals don't equal velocity -- or should
            they? In Mike Cohn's book it seems to indicate velocity is based on
            historical estimates, not the actuals.

            -Nick
          • Wolfgang Schulze Zachau
            In my opinion, velocity is a measure that is used in two ways: finding the approximate size of the chunk that can be done in the next sprint and providing high
            Message 5 of 19 , Aug 2 1:42 AM
            • 0 Attachment
              In my opinion, velocity is a measure that is used in two ways: finding the
              approximate size of the chunk that can be done in the next sprint and
              providing high level predictions of when a product can reach a certain set
              functionality with given resources (for whom a velocity has been
              established). Considering this and the fact that estimations in hours should
              only (if at all) be used within a sprint when the team starts planning the
              actual sprint, I'd say that using hours in velocity is probably not very
              useful.
              From personal experience I would advise against using hours at all. It took
              me some time to convince our PO, but he now has come to realize that the
              inner workings of a team within a sprint are actually not important to him,
              because he can rely on the fact that at the end of the sprint he will
              usually get what the team promised. In consequence we have dropped the
              estimation of tasks in hours (it was just wasting time and therefore
              eliminated). We estimate our stories in an abstract size unit (similar to
              the T-shirt sizes mentioned by Chris Sterling in another post, except we
              have more sizes) which considers complexity, risk, duration, domain
              knowledge and ideal developer time. The accuracy is surprisingly high (after
              some sprints) and it is fast.

              IMO velocity should be calculated as a floating average over the last couple
              of sprints from the size units (gummi-bears, T-shorts, ...) of actual
              results delivered.

              Regards,

              Wolfgang



              > -----Original Message-----
              > From: scrumdevelopment@yahoogroups.com
              > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of
              > Nicholas Cancelliere
              > Sent: 02 August 2006 01:15
              > To: scrumdevelopment@yahoogroups.com
              > Subject: [scrumdevelopment] Velocity - Estimate or Actuals?
              >
              >
              > I've read that velocity is calculated using historical
              > estimates (what the team estimated and committed to) vs. the
              > actuals a team did. An example (condensed for easy math):
              >
              > 5 day iteration, three developers are expected to burn 5 hrs
              > a day (the other 3 hrs are slop/buffer for email, meetings,
              > etc - last day), there are 3 stories (for each developer).
              >
              > Story 1 - 20 hrs estimated - 22 actual
              > Story 2 - 20 hrs estimated - 38 actual
              > Story 3 - 20 hrs estimated - 18 actual
              >
              > Would you not then say the velocity as 78 (average of the 3 actuals,
              > 26 * 3), and maybe schedule 70-75 hrs next iteration, or is
              > it just 60. I am having a difficult time explaining this to
              > our project manager to understand why actuals don't equal
              > velocity -- or should they? In Mike Cohn's book it seems to
              > indicate velocity is based on historical estimates, not the actuals.
              >
              > -Nick
              >
              >
              >
              >
              >
            • Ron Jeffries
              Hello Nicholas, Thanks for your email. On Tuesday, August 1, 2006, at 8:15:03 PM, ... We accomplished 60 hours estimated this past iteration. Since we have no
              Message 6 of 19 , Aug 2 2:16 AM
              • 0 Attachment
                Hello Nicholas,

                Thanks for your email. On Tuesday, August 1, 2006, at 8:15:03 PM,
                you wrote:

                > I've read that velocity is calculated using historical estimates
                > (what the team estimated and committed to) vs. the actuals a team
                > did. An example (condensed for easy math):

                > 5 day iteration, three developers are expected to burn 5 hrs a day
                > (the other 3 hrs are slop/buffer for email, meetings, etc - last
                > day), there are 3 stories (for each developer).

                > Story 1 - 20 hrs estimated - 22 actual
                > Story 2 - 20 hrs estimated - 38 actual
                > Story 3 - 20 hrs estimated - 18 actual

                > Would you not then say the velocity as 78 (average of the 3 actuals,
                > 26 * 3), and maybe schedule 70-75 hrs next iteration, or is it just
                > 60. I am having a difficult time explaining this to our project
                > manager to understand why actuals don't equal velocity -- or should
                > they? In Mike Cohn's book it seems to indicate velocity is based on
                > historical estimates, not the actuals.

                We accomplished 60 hours estimated this past iteration. Since we
                have no reason to believe that our estimation will be any better
                next iteration, we should probably expect to do 60 hours estimated
                next time, and that it would again take about 78 hours. (By the way,
                a somewhat more efficient way to get 78 is to add up the actuals,
                not add them up, divide by three, and multiply by three. ;->)

                However, if I recall what the Scrum literature actually says, it is
                that the team should look at the work to be done and commit to it.
                IMO, blind reliance on these numbers is not as strong as looking
                each other in the eye and deciding to accomplish what's on the
                board.

                Ron Jeffries
                www.XProgramming.com
                Fatalism is born of the fear of failure, for we all believe that we carry
                success in our own hands, and we suspect that our hands are weak. -- Conrad
              • PaulOldfield1@aol.com
                (responding to Nick) Let me take a shot at this one from a differnt angle... ... Suppose we were estimating in story points and had estimated these each as 3
                Message 7 of 19 , Aug 2 4:34 AM
                • 0 Attachment
                  (responding to Nick)
                   
                  Let me take a shot at this one from a differnt angle...
                   
                  > 5 day iteration, three developers are expected to burn 5 hrs a
                  day 
                  > (the other 3 hrs are slop/buffer for email, meetings, etc -
                  last 
                  > day), there are 3 stories (for each
                  developer).
                  >
                  > Story 1 - 20 hrs estimated - 22 actual
                  > Story
                  2 - 20 hrs estimated - 38 actual
                  > Story 3 - 20 hrs estimated - 18
                  actual
                   
                  Suppose we were estimating in story points and had estimated
                  these each as 3 story points.  This is an arbitrary number
                  that somewhere in the back of our minds we may think
                  would normally take 20 hours.
                   
                  Suppose we had the capacity for 80 hours work per iteration.
                   
                  We may have expected to complete 12 story points worth
                  of work for the iteration, but actually we only completed 9.
                   
                  Going forward, what do we know at this time? 
                  - we know that 1 of our 3 point stories should have been a
                  6 point story.
                  - we know some of our 3 point story estimates were correct.
                  - we know there's a possibility of more of our estimates
                  being incorrect.
                  - we know that our current best guess of these inaccuracies
                  is that 1 in 3 of our stories should have its estimate doubled.
                   
                  Given that information, our best estimate of what we will be
                  able to attain next iteration is 9 story points.
                   
                  We now have a choice. 
                   
                  We know a bit more about where our estimates are wrong,
                  so we could try and re-estimate everything.  But if we do
                  this, what velocity should we use?  It could be anything
                  between 9 and 12.  Sometimes it's worth doing; sometimes
                  not.
                   
                  Alternatively we could say that we can live with the uncertainty
                  and carry on using 9 as our velocity.  This need not be as
                  bad as we might think, because our new knowledge on estimating
                  can be folded in to planning of the sprint.  We may choose,
                  at that time, to commit to more than 9 story points because,
                  given our current knowledge, the team believes it can commit
                  to them and deliver them this iteration.  The sprint planning
                  is the fine control, achieved primarily by what the team feel
                  they can commit to.  That's what really matters.
                   
                  Paul Oldfield
                • Clifford Gregory
                  Hi Nick, I am the patent holder on Velocity calcualtion in software development prediction. The key is to measure thing like complexity and effort or each
                  Message 8 of 19 , Aug 2 5:05 AM
                  • 0 Attachment
                    Hi Nick,

                    I am the patent holder on Velocity calcualtion in software development prediction.  The key is to measure thing like complexity and effort or each small interation and than to start charting that data, after a few interations you will be able to determine which coder is moving at which speed.  That is certainly helpful, but beyond that you need to account for those random happening like power outage, stuck in traffic and the like, that is where overall group snap shots make it work a lot better and finally, you need to gather the metric from raw code, not just swags from the staff.  Keep the creative staff free to create and have management mine and chart the progress data.  I am really happy to see interest in the question.

                    Best,

                    Cliff

                    ----- Original Message ----
                    From: Nicholas Cancelliere <nicholas@...>
                    To: scrumdevelopment@yahoogroups.com
                    Sent: Tuesday, August 1, 2006 7:49:03 PM
                    Subject: Re: [scrumdevelopment] Velocity - Estimate or Actuals?

                    I think you hit it on the nose.  I'd guess that when the PM hears the word "velocity" she's naturally thinking in terms of speed and how much work the team is able to process.  The subtle difference is the idea of the team's ability to demonstrate predict and deliver stories.  I'll try to explain it in this way and see how that goes over. 

                    The example was made up to demonstrate the point, but yeah if there was a 38 I'd want to know what went wrong there in the estimate.  



                    On Aug 1, 2006, at 8:24 PM, William Wake wrote:

                    On 8/1/06, Nicholas Cancelliere <nicholas@ozmox.com> wrote:
                    > I've read that velocity is calculated using historical estimates
                    > (what the team estimated and committed to) vs. the actuals a team
                    > did. An example (condensed for easy math):
                    >
                    > 5 day iteration, three developers are expected to burn 5 hrs a day
                    > (the other 3 hrs are slop/buffer for email, meetings, etc - last
                    > day), there are 3 stories (for each developer).
                    >
                    > Story 1 - 20 hrs estimated - 22 actual
                    > Story 2 - 20 hrs estimated - 38 actual
                    > Story 3 - 20 hrs estimated - 18 actual
                    >
                    > Would you not then say the velocity as 78 (average of the 3 actuals,
                    > 26 * 3), and maybe schedule 70-75 hrs next iteration, or is it just
                    > 60. I am having a difficult time explaining this to our project
                    > manager to understand why actuals don't equal velocity -- or should
                    > they? In Mike Cohn's book it seems to indicate velocity is based on
                    > historical estimates, not the actuals.

                    I use historical estimates (but I do try to get better estimates). I
                    look at velocity as, "what is the team's demonstrated ability to
                    predict and deliver stories?"

                    In the case at hand, it seems to me like you're talking about going
                    exactly the wrong direction. You tried to schedule 60 hours work, but
                    it ended up as 78 (~30% over the prediction). For you to actually
                    schedule 60 hours work, it seems you should have planned ~45 hours.

                    (In this case, it looks like 2 stories were close to their estimate,
                    one was way over. I'd want to understand what happened there. Is it
                    something that's going to affect a certain class of story?)

                    What I'd do:
                    - re-estimate the remaining stories in light of what I learned this time
                    - estimate 60 as my velocity for next iteration.
                    - deliver those 60 and expect/hope to ask for more stories (raising
                    your velocity)

                    (We expect to do more, as we believe our estimates are now more accurate.)

                    I prefer to let velocity be a "trailing" indicator in this sense, as a
                    measure of our *demonstrated* ability to deliver.

                    --
                    Bill Wake William.Wake@acm.org www.xp123.com



                  • Nicholas Cancelliere
                    That makes sense. (The bit about the average -- the reason I say 26 * 3 ... is because the assumption is that instead of each developer doing 20 pts, they
                    Message 9 of 19 , Aug 2 5:09 AM
                    • 0 Attachment

                      That makes sense.  

                      (The bit about the average -- the reason I say 26 * 3 ... is because the assumption is that instead of each developer doing 20 pts, they might do 25.  We generally assign each developer X pts - so if the team has 4 members it'd be able to do 100 pts of work.  If the team adds a member we say it can do 125 pts, and if it looses one 75, etc.  Granted, it's just a guess - but when a team has a resource added we need a starting point for the velocity -- of course over time the new team makeup we might find it changes)

                      On Aug 2, 2006, at 4:16 AM, Ron Jeffries wrote:


                      We accomplished 60 hours estimated this past iteration. Since we
                      have no reason to believe that our estimation will be any better
                      next iteration, we should probably expect to do 60 hours estimated
                      next time, and that it would again take about 78 hours. (By the way,
                      a somewhat more efficient way to get 78 is to add up the actuals,
                      not add them up, divide by three, and multiply by three. ;->)

                      However, if I recall what the Scrum literature actually says, it is
                      that the team should look at the work to be done and commit to it.
                      IMO, blind reliance on these numbers is not as strong as looking
                      each other in the eye and deciding to accomplish what's on the
                      board.

                      Ron Jeffries
                      www.XProgramming.com
                      Fatalism is born of the fear of failure, for we all believe that we carry
                      success in our own hands, and we suspect that our hands are weak. -- Conrad


                    • Ron Jeffries
                      Hello Nicholas, Thank you for your email. On Wednesday, August 2, 2006, at 8:09:19 ... Numerology, mostly, it seems to me. Ron Jeffries www.XProgramming.com I
                      Message 10 of 19 , Aug 2 5:30 AM
                      • 0 Attachment
                        Hello Nicholas,

                        Thank you for your email. On Wednesday, August 2, 2006, at 8:09:19
                        AM, you wrote:


                        > (The bit about the average -- the reason I say 26 * 3 ... is because
                        > the assumption is that instead of each developer doing 20 pts, they
                        > might do 25. We generally assign each developer X pts - so if the
                        > team has 4 members it'd be able to do 100 pts of work. If the team
                        > adds a member we say it can do 125 pts, and if it looses one 75,
                        > etc. Granted, it's just a guess - but when a team has a resource
                        > added we need a starting point for the velocity -- of course over
                        > time the new team makeup we might find it changes)

                        Numerology, mostly, it seems to me.

                        Ron Jeffries
                        www.XProgramming.com
                        I could be wrong, of course. It's just not the way to bet.
                      • Steven Gordon
                        ... Cliff, I apologize for ripping you off for years now. I had been assuming Velocity was public domain since so many different people have been presenting
                        Message 11 of 19 , Aug 2 6:31 AM
                        • 0 Attachment
                          On 8/2/06, Clifford Gregory <cliff_gregory@...> wrote:
                          >
                          > Hi Nick,
                          >
                          > I am the patent holder on Velocity calcualtion in software development
                          > prediction.

                          Cliff,

                          I apologize for ripping you off for years now. I had been assuming
                          Velocity was public domain since so many different people have been
                          presenting the idea without attribution.

                          BTW, what is the number for that patent?

                          Regards,

                          Steve
                        • David H.
                          ... Searching US Patents Text Collection... Results of Search in US Patents Text Collection db for: IN/Clifford-Gregory: 0 patents. No patents have matched
                          Message 12 of 19 , Aug 2 6:48 AM
                          • 0 Attachment
                            On 02/08/06, Steven Gordon <sgordonphd@...> wrote:
                            > On 8/2/06, Clifford Gregory <cliff_gregory@...> wrote:
                            > >
                            > > Hi Nick,
                            > >
                            > > I am the patent holder on Velocity calcualtion in software development
                            > > prediction.
                            >
                            > Cliff,
                            >
                            > I apologize for ripping you off for years now. I had been assuming
                            > Velocity was public domain since so many different people have been
                            > presenting the idea without attribution.
                            >
                            > BTW, what is the number for that patent?
                            >
                            Searching US Patents Text Collection...

                            Results of Search in US Patents Text Collection db for:
                            IN/Clifford-Gregory: 0 patents.

                            No patents have matched your query


                            We need you real name man Clifford :)


                            --
                            Sent from gmail so do not trust this communication.
                            Do not send me sensitive information here, ask for my none-gmail accounts.

                            "Therefore the considerations of the intelligent always include both
                            benefit and harm." - Sun Tzu
                          • Ron Jeffries
                            Hello Steven, Thank you for your ideas. On Wednesday, August 2, 2006, at 9:31:10 ... And the date? There may be prior art. ;- Ron Jeffries
                            Message 13 of 19 , Aug 2 10:11 AM
                            • 0 Attachment
                              Hello Steven,

                              Thank you for your ideas. On Wednesday, August 2, 2006, at 9:31:10
                              AM, you wrote:


                              > I apologize for ripping you off for years now. I had been assuming
                              > Velocity was public domain since so many different people have been
                              > presenting the idea without attribution.

                              > BTW, what is the number for that patent?

                              And the date? There may be prior art. ;->

                              Ron Jeffries
                              www.XProgramming.com
                              One test is worth a thousand expert opinions.
                              -- Bill Nye (The Science Guy)
                            • Nicholas Cancelliere
                              How would you adjust a velocity of a team then if you added say 2 developers - if not by looking at the current velocity and trying to determine the average
                              Message 14 of 19 , Aug 2 12:53 PM
                              • 0 Attachment

                                How would you adjust a velocity of a team then if you added say 2 developers - if not by looking at the current velocity and trying to determine the average per developer and then apply that to the new resources?  Would you just go forward with the same velocity as last sprint, or make a guess based on what the average per dev was, or just guess without any historical data?

                                Nick



                                On Aug 2, 2006, at 7:30 AM, Ron Jeffries wrote:

                                Hello Nicholas,

                                Thank you for your email. On Wednesday, August 2, 2006, at 8:09:19
                                AM, you wrote:

                                > (The bit about the average -- the reason I say 26 * 3 ... is because
                                > the assumption is that instead of each developer doing 20 pts, they
                                > might do 25. We generally assign each developer X pts - so if the
                                > team has 4 members it'd be able to do 100 pts of work. If the team
                                > adds a member we say it can do 125 pts, and if it looses one 75,
                                > etc. Granted, it's just a guess - but when a team has a resource
                                > added we need a starting point for the velocity -- of course over
                                > time the new team makeup we might find it changes)

                                Numerology, mostly, it seems to me.

                                Ron Jeffries
                                www.XProgramming.com
                                I could be wrong, of course. It's just not the way to bet.


                              • Jeff Heinen
                                Since adding new folks to the team often results in an immediate *loss* of overall productivity until the new folks get ramped up, I d tend to not adjust the
                                Message 15 of 19 , Aug 2 3:51 PM
                                • 0 Attachment
                                  Since adding new folks to the team often results in an immediate *loss* of overall productivity until the new folks get ramped up, I'd tend to not adjust the velocity and give it a couple of sprints and observe what happens. I certainly wouldn't make any committents around a projected new velocity until I saw what it actually was empirically.
                                   
                                  -Jeff H.


                                  From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Nicholas Cancelliere
                                  Sent: Wednesday, August 02, 2006 12:54 PM
                                  To: scrumdevelopment@yahoogroups.com
                                  Subject: Re: [scrumdevelopment] Velocity - Estimate or Actuals?


                                  How would you adjust a velocity of a team then if you added say 2 developers - if not by looking at the current velocity and trying to determine the average per developer and then apply that to the new resources?  Would you just go forward with the same velocity as last sprint, or make a guess based on what the average per dev was, or just guess without any historical data?

                                  Nick



                                  On Aug 2, 2006, at 7:30 AM, Ron Jeffries wrote:

                                  Hello Nicholas,

                                  Thank you for your email. On Wednesday, August 2, 2006, at 8:09:19
                                  AM, you wrote:

                                  > (The bit about the average -- the reason I say 26 * 3 ... is because
                                  > the assumption is that instead of each developer doing 20 pts, they
                                  > might do 25. We generally assign each developer X pts - so if the
                                  > team has 4 members it'd be able to do 100 pts of work. If the team
                                  > adds a member we say it can do 125 pts, and if it looses one 75,
                                  > etc. Granted, it's just a guess - but when a team has a resource
                                  > added we need a starting point for the velocity -- of course over
                                  > time the new team makeup we might find it changes)

                                  Numerology, mostly, it seems to me.

                                  Ron Jeffries
                                  www.XProgramming. com
                                  I could be wrong, of course. It's just not the way to bet.


                                • Paul Hodgetts
                                  ... I think the key point is that the team wouldn t make a commitment to any sprint, even with a constant number of people, based on velocity numbers. They
                                  Message 16 of 19 , Aug 2 5:44 PM
                                  • 0 Attachment
                                    Nicholas Cancelliere asked:

                                    > How would you adjust a velocity of a team then if you added
                                    > say 2 developers - if not by looking at the current velocity
                                    > and trying to determine the average per developer and then
                                    > apply that to the new resources? Would you just go forward
                                    > with the same velocity as last sprint, or make a guess based
                                    > on what the average per dev was, or just guess without any
                                    > historical data?

                                    I think the key point is that the team wouldn't make a
                                    commitment to any sprint, even with a constant number of
                                    people, based on velocity numbers. They sit down together,
                                    look at the stories on the top of the backlog, discuss how
                                    they see things playing out, and then commit to what they
                                    think they can get done with whatever level of "certainty"
                                    they and the organization are looking for. IMHO, it's all
                                    too easy to try to make it a "data-driven" process, but it's
                                    not.

                                    When changing the team makeup, all bets are off on the next
                                    sprint's velocity. It probably won't go up in some proportion
                                    to what the previous team makeup was doing. In a lot of cases,
                                    it goes down while incorporating the new team members. I
                                    don't think any magic velocity adjustment calculations will
                                    help more than the team sitting down together and figuring out
                                    what they think they can accomplish with the new team makeup.

                                    So, to answer your question, I wouldn't even try to "adjust"
                                    the velocity. I'd let the team commit for the next sprint,
                                    and then see what actually happened.

                                    If everything is in a stable state (the team makeup, the
                                    context and environment, as well as the estimates on the
                                    stories), we can use the historical velocity as an average
                                    guess for longer-term planning, with some appropriate error
                                    bar, and tempered by our judgement and common sense. Sprint
                                    by sprint, I'd expect the velocity to be close, but in my
                                    experience it still flutters around a bit due to all the
                                    variables involved.

                                    Paul
                                    -----
                                    Paul Hodgetts -- CEO, Coach, Trainer, Consultant
                                    Agile Logic -- www.agilelogic.com
                                    Training, Coaching, Consulting -- Agile Processes/Scrum/Lean/XP
                                    Complete solutions for adopting agile processes, Scrum and XP.
                                  • Clifford Gregory
                                    I consider it a complement to use this data, and not a rip off. Here is the notice, and as you can see it was issued Dec 29 of 2005. It was written almost 3
                                    Message 17 of 19 , Aug 7 10:34 AM
                                    • 0 Attachment
                                      I consider it a complement to use this data, and not a rip off.  Here is the notice, and as you can see it was issued Dec 29 of 2005.  It was written almost 3 or 4 years before, but those guys are slow.  The term "velocity" is not the real subject it is the graphs and calculations. 

                                      Best,

                                      Cliff
                                      "Cliff,

                                      This is to inform you that the U.S. utility patent application for the project velocity development was published on December 29, 2005 as Publication No. US-2005-0289503-A1.  The direct link to access the published application is http://www.uspto.gov/patft/
                                      Best regards,

                                      Bill"


                                      ----- Original Message ----
                                      From: David H. <dmalloc@...>
                                      To: scrumdevelopment@yahoogroups.com
                                      Sent: Wednesday, August 2, 2006 6:48:19 AM
                                      Subject: Re: [scrumdevelopment] Velocity - Estimate or Actuals?

                                      On 02/08/06, Steven Gordon <sgordonphd@gmail. com> wrote:
                                      > On 8/2/06, Clifford Gregory <cliff_gregory@ yahoo.com> wrote:
                                      > >
                                      > > Hi Nick,
                                      > >
                                      > > I am the patent holder on Velocity calcualtion in software development
                                      > > prediction.
                                      >
                                      > Cliff,
                                      >
                                      > I apologize for ripping you off for years now. I had been assuming
                                      > Velocity was public domain since so many different people have been
                                      > presenting the idea without attribution.
                                      >
                                      > BTW, what is the number for that patent?
                                      >
                                      Searching US Patents Text Collection.. .

                                      Results of Search in US Patents Text Collection db for:
                                      IN/Clifford- Gregory: 0 patents.

                                      No patents have matched your query

                                      We need you real name man Clifford :)

                                      --
                                      Sent from gmail so do not trust this communication.
                                      Do not send me sensitive information here, ask for my none-gmail accounts.

                                      "Therefore the considerations of the intelligent always include both
                                      benefit and harm." - Sun Tzu


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