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

'Velocity' Terminology: Points / Hour vs Points / Sprint

Expand Messages
  • mattwynneatfastmail
    Hi, In order to try to even out the effect of fluctuations in the man-power availlable on any given sprint, we have been monitoring our velocity in terms of
    Message 1 of 7 , Jul 4, 2007
      Hi,

      In order to try to even out the effect of fluctuations in the
      man-power availlable on any given sprint, we have been monitoring our
      velocity in terms of the number of story-points completed during a
      sprint, versus the number of man-hours booked to the project during
      that sprint.

      This is obviously a different metric from the classic scrum 'velocity'
      I was taught by Mike Cohn, which simply measures the number of points
      a team completes each sprint.

      The term 'velocity' has come to be used in our organisation to
      describe the former, and I'm wondering whether we should be using a
      different term for that metric, like 'efficiency' maybe?

      It's like the two metrics tell you different things: the 'efficiency'
      could be used to forecast schedules based on knowledge of holiday
      plans, resourcing (though obviously changes in team structure could
      affect the velocity) but what it's best at is giving you a health
      check on how well the team are working together - if this efficiency
      dips, something is wrong.

      The latter (traditional 'velocity') just gives you a rough
      predictability of delivery, and (assuming team members take holidays
      etc) not a lot more. I wonder whether it's deliverabely rough since
      this is not an exact science?

      Anyway, I'd appreciate thoughts on the differences between the two
      metrics, and the terminology that others use for them.

      thanks,
      Matt
    • Mike Cohn
      Hi Matt-- I use the term capacity to refer to the y (vertical) intercept of a team s sprint burndown chart. That is how many hours they plan into a sprint.
      Message 2 of 7 , Jul 4, 2007
        Hi Matt--
        I use the term "capacity" to refer to the y (vertical) intercept of a team's sprint burndown chart. That is how many hours they plan into a sprint. It will be fairly stable (once a team gets a handle on sprint planning) but will vary (as you say) based on holidays, etc. 
        I use velocity to refer to the amount of work done as expressed in the units the team uses to estimate their product backlog--preferably story points or some relative unit of size. This will bounce around a bit more in the same way that a basketball team doesn't score exactly the same number of points each game. It can be (as you say), though, a useful long-term predictor.

        Regards,
        Mike Cohn
        Author:
          Agile Estimating and Planning
          User Stories Applied
        www.mountaingoatsoftware.com


        On Jul 4, 2007, at 8:45 AM, mattwynneatfastmail wrote:

        Hi,

        In order to try to even out the effect of fluctuations in the
        man-power availlable on any given sprint, we have been monitoring our
        velocity in terms of the number of story-points completed during a
        sprint, versus the number of man-hours booked to the project during
        that sprint.

        This is obviously a different metric from the classic scrum 'velocity'
        I was taught by Mike Cohn, which simply measures the number of points
        a team completes each sprint.

        The term 'velocity' has come to be used in our organisation to
        describe the former, and I'm wondering whether we should be using a
        different term for that metric, like 'efficiency' maybe?

        It's like the two metrics tell you different things: the 'efficiency'
        could be used to forecast schedules based on knowledge of holiday
        plans, resourcing (though obviously changes in team structure could
        affect the velocity) but what it's best at is giving you a health
        check on how well the team are working together - if this efficiency
        dips, something is wrong.

        The latter (traditional 'velocity') just gives you a rough
        predictability of delivery, and (assuming team members take holidays
        etc) not a lot more. I wonder whether it's deliverabely rough since
        this is not an exact science?

        Anyway, I'd appreciate thoughts on the differences between the two
        metrics, and the terminology that others use for them.

        thanks,
        Matt


      • mattwynneatfastmail
        Hi Mike, The metric I m talking about is a lot like your velocity, but it s evened-out for days off, because rather than using one sprint as the denominator
        Message 3 of 7 , Jul 4, 2007
          Hi Mike,

          The metric I'm talking about is a lot like your velocity, but it's
          evened-out for days off, because rather than using 'one sprint' as the
          denominator in the ratio, we use the number of man-hours or man-days
          booked to the project during the sprint.

          So, for example where you might talk about 'looking at the last
          sprint, the team is running at a velocity of 54 points per sprint' we
          would say something like 'looking at the last sprint, the team is
          running at a velocity of 0.7 points per man-day'

          I don't like using the word velocity here (though we do) because it's
          a different metric to yours, and yours came first! I wondered if other
          people were using the same metric as me, and whether that had a name.

          I think 'efficiency' might be the term.

          I'm also a little worried that we're being slightly over-scientific
          and potentially giving the impression that things are more predicable
          than they really are.


          --- In scrumdevelopment@yahoogroups.com, Mike Cohn <mike@...> wrote:
          >
          > Hi Matt--
          > I use the term "capacity" to refer to the y (vertical) intercept of a
          > team's sprint burndown chart. That is how many hours they plan into a
          > sprint. It will be fairly stable (once a team gets a handle on sprint
          > planning) but will vary (as you say) based on holidays, etc.
          > I use velocity to refer to the amount of work done as expressed in
          > the units the team uses to estimate their product backlog--preferably
          > story points or some relative unit of size. This will bounce around a
          > bit more in the same way that a basketball team doesn't score exactly
          > the same number of points each game. It can be (as you say), though,
          > a useful long-term predictor.
          >
          > Regards,
          > Mike Cohn
          > Author:
          > Agile Estimating and Planning
          > User Stories Applied
          > www.mountaingoatsoftware.com
          >
          >
          > On Jul 4, 2007, at 8:45 AM, mattwynneatfastmail wrote:
          >
          > > Hi,
          > >
          > > In order to try to even out the effect of fluctuations in the
          > > man-power availlable on any given sprint, we have been monitoring our
          > > velocity in terms of the number of story-points completed during a
          > > sprint, versus the number of man-hours booked to the project during
          > > that sprint.
          > >
          > > This is obviously a different metric from the classic scrum 'velocity'
          > > I was taught by Mike Cohn, which simply measures the number of points
          > > a team completes each sprint.
          > >
          > > The term 'velocity' has come to be used in our organisation to
          > > describe the former, and I'm wondering whether we should be using a
          > > different term for that metric, like 'efficiency' maybe?
          > >
          > > It's like the two metrics tell you different things: the 'efficiency'
          > > could be used to forecast schedules based on knowledge of holiday
          > > plans, resourcing (though obviously changes in team structure could
          > > affect the velocity) but what it's best at is giving you a health
          > > check on how well the team are working together - if this efficiency
          > > dips, something is wrong.
          > >
          > > The latter (traditional 'velocity') just gives you a rough
          > > predictability of delivery, and (assuming team members take holidays
          > > etc) not a lot more. I wonder whether it's deliverabely rough since
          > > this is not an exact science?
          > >
          > > Anyway, I'd appreciate thoughts on the differences between the two
          > > metrics, and the terminology that others use for them.
          > >
          > > thanks,
          > > Matt
          > >
          > >
          > >
          >
        • Mike Cohn
          HI Matt-- Yes, I would say you re getting a false level of precision there. A rule of thumb for me is that I will only track things if they are
          Message 4 of 7 , Jul 4, 2007
            HI Matt--
            Yes, I would say you're getting a false level of precision there. A rule of thumb for me is that I will only track things if they are actionable--that is, if tracking this number will lead me to make different decisions than I would without it then I might track it. I have of course tried tracking a number like you describe but never found it leading us to make different decisions. In those cases we called it either "Adjusted Velocity" or "Normalized Velocity." I've never done it to the level of hours because I want to make the assumption that the hours of available will be roughly the same from sprint to sprint  over the long term. We have done it by days worked. 

            Today is a good example since it's a holiday in the US. In fact I just walked over to the Chinese restaurant next to my office and they're closed all day as are many software teams. Suppose our sprints are 10-days long and one ended last Friday. There were five us on the sprint and we each worked 10 days. We had a velocity of 30. For that sprint I would have reported our velocity as 30 (points) / 50 (days worked) and got 0.6 as our "normalized velocity."  In the current sprint we achieve a velocity of let's say 31. (I'll explain that in a minute.) Since it's a holiday today we are all off today and I'm going to take the next two days off as well while my team members all come to work. In the current sprint we then work a total of 43 days. Our normalized velocity would be 31 (points) / 43 (days) or 0.72. 

            I chose 31 as the second sprint velocity even though we might think it would be lower (say 27) since we're all off for a day. What I've found over doing this on hundreds of sprints and dozens of teams was that tracking a normalized velocity such as this wasn't useful because the normal statistical fluctuation in velocity (the numerator) was more significant than the changes in the denominator (days worked as affected by vacation, holidays, etc.) That is, simply looking at average velocity ranges was equally as predictive as normalizing for days worked. 

            Regards,
            Mike Cohn
            Author:
              Agile Estimating and Planning
              User Stories Applied
            www.mountaingoatsoftware.com


            On Jul 4, 2007, at 11:43 AM, mattwynneatfastmail wrote:

            Hi Mike,

            The metric I'm talking about is a lot like your velocity, but it's
            evened-out for days off, because rather than using 'one sprint' as the
            denominator in the ratio, we use the number of man-hours or man-days
            booked to the project during the sprint.

            So, for example where you might talk about 'looking at the last
            sprint, the team is running at a velocity of 54 points per sprint' we
            would say something like 'looking at the last sprint, the team is
            running at a velocity of 0.7 points per man-day'

            I don't like using the word velocity here (though we do) because it's
            a different metric to yours, and yours came first! I wondered if other
            people were using the same metric as me, and whether that had a name.

            I think 'efficiency' might be the term.

            I'm also a little worried that we're being slightly over-scientific
            and potentially giving the impression that things are more predicable
            than they really are.

            --- In scrumdevelopment@yahoogroups.com, Mike Cohn <mike@...> wrote:
            >
            > Hi Matt--
            > I use the term "capacity" to refer to the y (vertical) intercept of a
            > team's sprint burndown chart. That is how many hours they plan into a
            > sprint. It will be fairly stable (once a team gets a handle on sprint
            > planning) but will vary (as you say) based on holidays, etc.
            > I use velocity to refer to the amount of work done as expressed in
            > the units the team uses to estimate their product backlog--preferably
            > story points or some relative unit of size. This will bounce around a
            > bit more in the same way that a basketball team doesn't score exactly
            > the same number of points each game. It can be (as you say), though,
            > a useful long-term predictor.
            >
            > Regards,
            > Mike Cohn
            > Author:
            > Agile Estimating and Planning
            > User Stories Applied
            > www.mountaingoatsoftware.com
            >
            >
            > On Jul 4, 2007, at 8:45 AM, mattwynneatfastmail wrote:
            >
            > > Hi,
            > >
            > > In order to try to even out the effect of fluctuations in the
            > > man-power availlable on any given sprint, we have been monitoring our
            > > velocity in terms of the number of story-points completed during a
            > > sprint, versus the number of man-hours booked to the project during
            > > that sprint.
            > >
            > > This is obviously a different metric from the classic scrum 'velocity'
            > > I was taught by Mike Cohn, which simply measures the number of points
            > > a team completes each sprint.
            > >
            > > The term 'velocity' has come to be used in our organisation to
            > > describe the former, and I'm wondering whether we should be using a
            > > different term for that metric, like 'efficiency' maybe?
            > >
            > > It's like the two metrics tell you different things: the 'efficiency'
            > > could be used to forecast schedules based on knowledge of holiday
            > > plans, resourcing (though obviously changes in team structure could
            > > affect the velocity) but what it's best at is giving you a health
            > > check on how well the team are working together - if this efficiency
            > > dips, something is wrong.
            > >
            > > The latter (traditional 'velocity') just gives you a rough
            > > predictability of delivery, and (assuming team members take holidays
            > > etc) not a lot more. I wonder whether it's deliverabely rough since
            > > this is not an exact science?
            > >
            > > Anyway, I'd appreciate thoughts on the differences between the two
            > > metrics, and the terminology that others use for them.
            > >
            > > thanks,
            > > Matt
            > >
            > >
            > >
            >


          • Quinton
            How many sprints does it take to find a team s velocity? We ve had 7, and no clue of velocity. We find when a new member joins the team, or an experienced
            Message 5 of 7 , Jul 4, 2007
              How many sprints does it take to find a team's velocity?  We've had 7,  and no clue of velocity.
               
              We find when a new member joins the team, or an experienced one leaves, our velocity decreases, but our higher up bosses want to pretend that doesn't happen.
               
              I think we've fallen back into waterfall - we were not able to automate test cases - because of the architecture of a 6 year old product, and are trying to ship, but never really had a shippable product in the first 5 sprints.
               
              From what I see, the other departments that are working on new projects are fine, but our 6 year old code, that is just being updated, is not squishing into Agile / Srum very well.
               
              That said, I'm in QA, and a lot more attention is being paid to testing, but that might just be our new Project Owner, not necessarily Agile / Scrum, since we have no more automated tests than we had before we started.
               
               
              ----- Original Message -----
              From: Mike Cohn
              Sent: Wednesday, July 04, 2007 10:58 AM
              Subject: Re: [scrumdevelopment] Re: 'Velocity' Terminology: Points / Hour vs Points / Sprint

              HI Matt--

              Yes, I would say you're getting a false level of precision there. A rule of thumb for me is that I will only track things if they are actionable-- that is, if tracking this number will lead me to make different decisions than I would without it then I might track it. I have of course tried tracking a number like you describe but never found it leading us to make different decisions. In those cases we called it either "Adjusted Velocity" or "Normalized Velocity." I've never done it to the level of hours because I want to make the assumption that the hours of available will be roughly the same from sprint to sprint  over the long term. We have done it by days worked. 

              Today is a good example since it's a holiday in the US. In fact I just walked over to the Chinese restaurant next to my office and they're closed all day as are many software teams. Suppose our sprints are 10-days long and one ended last Friday. There were five us on the sprint and we each worked 10 days. We had a velocity of 30. For that sprint I would have reported our velocity as 30 (points) / 50 (days worked) and got 0.6 as our "normalized velocity."  In the current sprint we achieve a velocity of let's say 31. (I'll explain that in a minute.) Since it's a holiday today we are all off today and I'm going to take the next two days off as well while my team members all come to work. In the current sprint we then work a total of 43 days. Our normalized velocity would be 31 (points) / 43 (days) or 0.72. 

              I chose 31 as the second sprint velocity even though we might think it would be lower (say 27) since we're all off for a day. What I've found over doing this on hundreds of sprints and dozens of teams was that tracking a normalized velocity such as this wasn't useful because the normal statistical fluctuation in velocity (the numerator) was more significant than the changes in the denominator (days worked as affected by vacation, holidays, etc.) That is, simply looking at average velocity ranges was equally as predictive as normalizing for days worked. 

              Regards,
              Mike Cohn
              Author:
                Agile Estimating and Planning
                User Stories Applied
              www.mountaingoatsof tware.com


              On Jul 4, 2007, at 11:43 AM, mattwynneatfastmail wrote:

              Hi Mike,

              The metric I'm talking about is a lot like your velocity, but it's
              evened-out for days off, because rather than using 'one sprint' as the
              denominator in the ratio, we use the number of man-hours or man-days
              booked to the project during the sprint.

              So, for example where you might talk about 'looking at the last
              sprint, the team is running at a velocity of 54 points per sprint' we
              would say something like 'looking at the last sprint, the team is
              running at a velocity of 0.7 points per man-day'

              I don't like using the word velocity here (though we do) because it's
              a different metric to yours, and yours came first! I wondered if other
              people were using the same metric as me, and whether that had a name.

              I think 'efficiency' might be the term.

              I'm also a little worried that we're being slightly over-scientific
              and potentially giving the impression that things are more predicable
              than they really are.

              --- In scrumdevelopment@ yahoogroups. com, Mike Cohn <mike@...> wrote:
              >
              > Hi Matt--
              > I use the term "capacity" to refer to the y (vertical) intercept of a
              > team's sprint burndown chart. That is how many hours they plan into a
              > sprint. It will be fairly stable (once a team gets a handle on sprint
              > planning) but will vary (as you say) based on holidays, etc.
              > I use velocity to refer to the amount of work done as expressed in
              > the units the team uses to estimate their product backlog--preferably
              > story points or some relative unit of size. This will bounce around a
              > bit more in the same way that a basketball team doesn't score exactly
              > the same number of points each game. It can be (as you say), though,
              > a useful long-term predictor.
              >
              > Regards,
              > Mike Cohn
              > Author:
              > Agile Estimating and Planning
              > User Stories Applied
              > www.mountaingoatsof tware.com
              >
              >
              > On Jul 4, 2007, at 8:45 AM, mattwynneatfastmail wrote:
              >
              > > Hi,
              > >
              > > In order to try to even out the effect of fluctuations in the
              > > man-power availlable on any given sprint, we have been monitoring our
              > > velocity in terms of the number of story-points completed during a
              > > sprint, versus the number of man-hours booked to the project during
              > > that sprint.
              > >
              > > This is obviously a different metric from the classic scrum 'velocity'
              > > I was taught by Mike Cohn, which simply measures the number of points
              > > a team completes each sprint.
              > >
              > > The term 'velocity' has come to be used in our organisation to
              > > describe the former, and I'm wondering whether we should be using a
              > > different term for that metric, like 'efficiency' maybe?
              > >
              > > It's like the two metrics tell you different things: the 'efficiency'
              > > could be used to forecast schedules based on knowledge of holiday
              > > plans, resourcing (though obviously changes in team structure could
              > > affect the velocity) but what it's best at is giving you a health
              > > check on how well the team are working together - if this efficiency
              > > dips, something is wrong.
              > >
              > > The latter (traditional 'velocity') just gives you a rough
              > > predictability of delivery, and (assuming team members take holidays
              > > etc) not a lot more. I wonder whether it's deliverabely rough since
              > > this is not an exact science?
              > >
              > > Anyway, I'd appreciate thoughts on the differences between the two
              > > metrics, and the terminology that others use for them.
              > >
              > > thanks,
              > > Matt
              > >
              > >
              > >
              >


            • George Dinwiddie
              ... What has the teams velocity been for each of those 7 sprints? And how long are your sprints. ... It sounds like a real problem. There s no doubt that a
              Message 6 of 7 , Jul 4, 2007
                Quinton wrote:
                > How many sprints does it take to find a team's velocity? We've had 7,
                > and no clue of velocity.

                What has the teams velocity been for each of those 7 sprints? And how
                long are your sprints.

                > We find when a new member joins the team, or an experienced one leaves,
                > our velocity decreases, but our higher up bosses want to pretend that
                > doesn't happen.
                >
                > I think we've fallen back into waterfall - we were not able to automate
                > test cases - because of the architecture of a 6 year old product, and
                > are trying to ship, but never really had a shippable product in the
                > first 5 sprints.
                >
                > From what I see, the other departments that are working on new projects
                > are fine, but our 6 year old code, that is just being updated, is not
                > squishing into Agile / Srum very well.

                It sounds like a real problem. There's no doubt that a legacy code base
                is much harder for getting started. Generally they're hard to test,
                simply because no one concentrated on that aspect. You may want to
                consider bringing in a consultant to help you, as it's hard to see
                what's going on via email.

                That said, I'll certainly give you the best advice I can.

                > That said, I'm in QA, and a lot more attention is being paid to testing,
                > but that might just be our new Project Owner, not necessarily Agile /
                > Scrum, since we have no more automated tests than we had before we started.

                Can you find one little test you can automate? Sometimes a small
                success helps things get started in a big way. What's the impediment to
                automated testing?

                - George

                --
                ----------------------------------------------------------------------
                * George Dinwiddie * http://blog.gdinwiddie.com
                Software Development http://www.idiacomputing.com
                Consultant and Coach http://www.agilemaryland.org
                ----------------------------------------------------------------------
              • Petri Heiramo
                Hi Matt, Mike already had good answers from his vast background, but I would like to chip in something from my smaller experience, too. ... We have many
                Message 7 of 7 , Jul 5, 2007
                  Hi Matt,


                  Mike already had good answers from his vast background, but I would
                  like to chip in something from my smaller experience, too.

                  > In order to try to even out the effect of fluctuations in the
                  > man-power availlable on any given sprint, we have been monitoring our
                  > velocity in terms of the number of story-points completed during a
                  > sprint, versus the number of man-hours booked to the project during
                  > that sprint.

                  We have many projects that are experiencing similar situations. They
                  tend to be small teams and the absense of even one person for a few
                  days can have a significant effect on what the team can accomplish and
                  accurately commit to.

                  As a result, instead of using velocity for commitment, I have
                  suggested pre-estimating (in the sprint planning meeting) the
                  available days / hours the team would ideally have available. That is,
                  if there's three people for two week sprints, that's ideally 30 days.
                  Reduce that appropriately for absenses and part-timers. Then multiply
                  that with effective daily work hours (usually in the range of 5-6
                  ideal hours a day) for total estimated hours in the sprint.

                  Then estimate the tasks in ideal hours and pick stories up to that
                  maximum. If is not possible to make the choices at the same time (it
                  usually isn't), the team must consider the initial commitment in the
                  light of available time, then confirm that based on more detailed task
                  planning.

                  > This is obviously a different metric from the classic scrum 'velocity'
                  > I was taught by Mike Cohn, which simply measures the number of points
                  > a team completes each sprint.

                  http://www.agilekiwi.com/agile_charts.htm suggests ways to track
                  expended effort and comparing it to achieved results. That might give
                  you ideas for comparing "adjusted velocity" to the amount effort spent
                  in each sprint.

                  Btw, I think "adjusted velocity", a suggested by Mike, is a good term.
                  It keeps "velocity" as it's originally defined.

                  > It's like the two metrics tell you different things: the 'efficiency'
                  > could be used to forecast schedules based on knowledge of holiday
                  > plans, resourcing (though obviously changes in team structure could
                  > affect the velocity) but what it's best at is giving you a health
                  > check on how well the team are working together - if this efficiency
                  > dips, something is wrong.

                  If you use the charts in the link above, you should see the results
                  and effort climbing up at the same rate. If they don't, you can draw
                  some conclusions from it (just don't make them too hasty :).


                  Yours,


                  Petri Heiramo
                  Process Improvement Manager
                  SYSOPENDIGIA Plc., Finland
                Your message has been successfully submitted and would be delivered to recipients shortly.