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

Re: [scrumdevelopment] Velocity?

Expand Messages
  • Ravi Srinivasan
    Thanks to you all for the prompt response regarding the concept of velocity. I have few more basic questions on velocity…I will pick the definition that
    Message 1 of 22 , Mar 7, 2005
      Thanks to you all for the prompt response regarding
      the concept of velocity.

      I have few more basic questions on velocity�I will
      pick the definition that helped me best understand
      what the velocity means:

      "Velocity is essentially the amount of product
      completed over time." - Paul Hodgetts

      Additionally I found this:
      �The teams with which I've worked multiply their
      available days times an adjustment of 0.4 to 0.8 to
      get the number of ideal days they can accomplish, and
      that helps them figure out their velocity and what
      they can commit to in a sprint.� - Paul Hodgetts


      Is there any term in SCRUM around the value �0.4�
      mentioned above? 0.4 (or 40%) is used here as an
      estimation that will help the team define its
      velocity.
      This means that depending on the developer, the factor
      could be 40% or 80% and still achieve the velocity
      defined by the team. Right?


      Thanks
      Ravi

      --- Jeff Sutherland <jeff.sutherland@...>
      wrote:
      > Well, it may be confusing but it is high school
      > physics. You know that
      > about 20% of Americas think that the sun rotates
      > around the earth and
      > 45% of Americans think that water coming out of a
      > coiled hose will
      > flow in a spiral fashion. Not to mention another 45%
      > that think a ball
      > rolling off a table top will hit the floor directly
      > below the edge of
      > the table. An equal number think the earth was
      > created about 4000
      > years ago, but I digress.
      >
      > Velocity equals the rate of change of distance with
      > time. Acceleration
      > is the rate of change of velocity. This has nothing
      > to do with Scrum.
      >
      > In Scrum, the distance is amount of work done.
      >
      > However, we train people in CSM to use an ideal
      > developer day to
      > estimate work for their team. This concept of an
      > ideal developer day
      > will be different for different Scrum teams. Ergo,
      > productivity can be
      > different across teams with the same velocity.
      >
      > I don't see any new jargon here. We have been using
      > the same words for a decade.
      >
      > Jeff Sutherland
      >
      >
      > On Sun, 6 Mar 2005 11:36:48 -0800, Phlip
      > <phlip2005@...> wrote:
      > >
      > > Jeff Sutherland wrote:
      > >
      > > > Velocity is the rate of change of the burndown
      > chart. Ideally, the
      > > > burndown drops one day per team member every
      > day.
      > >
      > > This answer doubles the amount of undefined
      > jargon, and then adds a
      > > confusing ideal that implies one can _set_ the
      > velocity.
      > >
      > > Who do you think you are?
      > >
      > > Oh, wait. You think you are Jeff Sutherland.
      > >
      > > <impersonation voice="Emily Litela">Never
      > mind.</impersonation>
      > >
      > > --
      > > Phlip
      > >
      >
      http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
      >




      __________________________________
      Celebrate Yahoo!'s 10th Birthday!
      Yahoo! Netrospective: 100 Moments of the Web
      http://birthday.yahoo.com/netrospective/
    • Jeff Sutherland
      It is common for development teams to multiply their ideal developer day by a fraction to estimate the amount of work they get done in a day. If it is 0.40,
      Message 2 of 22 , Mar 7, 2005
        It is common for development teams to multiply their ideal developer
        day by a fraction to estimate the amount of work they get done in a
        day. If it is 0.40, they can only allocate 40% of the their day to the
        Sprint backlog.

        It is important for teams to be realistic, particularly in early
        Sprints. The most important thing is to actually complete the work
        they commit to in a Sprint. Once that is done repeatedly, they can
        focus on improving throughput within the Sprint.

        In my view, a 40% team is a very distracted team. I've seen teams run
        at more than 100% of their ideal developer day.

        The reality is that in most organizations a tremendous amount of work
        on blocking items must be undertaken to get teams to peak efficiency.
        That is the hard part of Scrum. The organization must undergo some
        business process reengineering in order for their development teams to
        function properly. People will come up with every reason, however
        improbable, to argue that their teams cannot possibly operate at peak
        efficiency. They will often say that the goal of their organization is
        really not higher productivity.

        They will say this as development jobs are being outsourced because it
        is cheaper to run an inefficient organization elsewhere. The really
        scary thing is that outsourcing organizations are beginning to adopt
        Scrum because it makes them highly competitive.

        Counterintuitively, the more efficiently the team runs, the higher the morale.

        Jeff Sutherland


        On Mon, 7 Mar 2005 12:34:42 -0800 (PST), Ravi Srinivasan
        <netlimit2000@...> wrote:
        >
        > Thanks to you all for the prompt response regarding
        > the concept of velocity.
        >
        > I have few more basic questions on velocity…I will
        > pick the definition that helped me best understand
        > what the velocity means:
        >
        > "Velocity is essentially the amount of product
        > completed over time." - Paul Hodgetts
        >
        > Additionally I found this:
        > "The teams with which I've worked multiply their
        > available days times an adjustment of 0.4 to 0.8 to
        > get the number of ideal days they can accomplish, and
        > that helps them figure out their velocity and what
        > they can commit to in a sprint." - Paul Hodgetts
        >
        > Is there any term in SCRUM around the value '0.4'
        > mentioned above? 0.4 (or 40%) is used here as an
        > estimation that will help the team define its
        > velocity.
        > This means that depending on the developer, the factor
        > could be 40% or 80% and still achieve the velocity
        > defined by the team. Right?
        >
        > Thanks
        > Ravi
      • Phlip
        ... That is loading factor . Some velocity estimations track the ratio of estimated time to actual time. That s why I used the definition the number of
        Message 3 of 22 , Mar 7, 2005
          Ravi Srinivasan wrote:
          >
          > Additionally I found this:
          > "The teams with which I've worked multiply their
          > available days times an adjustment of 0.4 to 0.8 to
          > get the number of ideal days they can accomplish, and
          > that helps them figure out their velocity and what
          > they can commit to in a sprint." - Paul Hodgetts
          >
          > Is there any term in SCRUM around the value '0.4'
          > mentioned above? 0.4 (or 40%) is used here as an
          > estimation that will help the team define its
          > velocity.

          That is "loading factor". Some velocity estimations track the ratio of
          estimated time to actual time.

          That's why I used the definition "the number of features completed in
          a week". There are those who request feature estimates in days, and
          who can then expect a velocity tick of one per day per developer. This
          requires math, that I hoped to avoid.

          > This means that depending on the developer, the factor
          > could be 40% or 80% and still achieve the velocity
          > defined by the team. Right?

          There is no benefit to tracking individual velocity. Conscientious
          individuals do this, for themselves, automatically, but if they don't
          it's no big deal. The team will know who is slacking.

          Put this another way: What would you do about a worker who was
          chronically lower than others? The answer is nothing. That worker
          might be the one who always takes on hard, stories, or the one who
          always helps boost others velocity.

          --
          Phlip
        • Paul Hodgetts
          ... In the book Agile Project Management with Scrum on page 11, Ken calls an adjustment made to an estimate a complexity factor. Unless I missed it, that
          Message 4 of 22 , Mar 7, 2005
            Ravi wrote:

            > Thanks to you all for the prompt response regarding
            > the concept of velocity.
            >
            > I have few more basic questions on velocity…I will
            > pick the definition that helped me best understand
            > what the velocity means:
            >
            > "Velocity is essentially the amount of product
            > completed over time." - Paul Hodgetts
            >
            > Additionally I found this:
            > “The teams with which I've worked multiply their
            > available days times an adjustment of 0.4 to 0.8 to
            > get the number of ideal days they can accomplish, and
            > that helps them figure out their velocity and what
            > they can commit to in a sprint.” - Paul Hodgetts
            >
            >
            > Is there any term in SCRUM around the value ‘0.4’
            > mentioned above? 0.4 (or 40%) is used here as an
            > estimation that will help the team define its
            > velocity.

            In the book "Agile Project Management with Scrum" on page 11,
            Ken calls an adjustment made to an estimate a "complexity
            factor." Unless I missed it, that book doesn't talk about
            adjustments applied to velocity, since velocity isn't really
            discuss as such. In the CSM courses, Ken calls an adjustment
            made to velocity "drag."

            > This means that depending on the developer, the factor
            > could be 40% or 80% and still achieve the velocity
            > defined by the team. Right?

            I fear there is a disconnect here in what I'm trying to
            describe and what you are understanding from it. The
            "factor of 40% or 80%" is used to estimate velocity. The
            team achieves whatever velocity they can really achieve.
            Let me try again from another angle...

            Let's assume we have a team of only programmers to simplify
            things. We have four of them dedicated full time to the
            project with only normal company overhead to consider.

            We estimate our product backlog items in ideal programmer
            days. In other words, if I had a perfect 8 hour day with
            no interruptions or overhead at all, how long would it take?

            We schedule a sprint from March 1 to March 31, within which
            there are 23 working days, taking into consideration the
            weekends (we have a life ;-).

            As a developer, if I had no overhead at all (in other words
            an "ideal day"), I my perfect velocity would be 23 ideal
            days of estimated work done in the sprint. Times 4 gives
            me a perfect velocity of 92 total ideal days of work that
            the team could do in the sprint.

            But days are not ideal, and conditions are not ideal. For
            example, I know I have 3 hours of meetings, and another hour
            of corporate paperwork to do. So I lose 4 hours a week,
            which means (given a 40 hour week), that I have to multiply
            my ideal velocity by 0.9 just to accommodate that.

            There are other things that reduce our velocity ("drag"
            using Ken's CSM term). Just the fact that we are learning
            Scrum and how to work as a self-managed team adds drag. If
            our environment is not ideal, for example our builds take
            too long or testing is hard, that adds drag. Teams that
            are not used to working together or are distributed across
            multiple locations add drag. So we can add up all the hours
            lost in a week to all the different drag producing things,
            and adjust for them as well.

            My experience is that a new Scrum team, on their first
            sprint, will need a drag adjustment of from 0.4 to 0.6. A
            Scrum team that has several sprints under their belt will
            have a better drag adjustment, maybe 0.6 to 0.8. I have
            never had a team at 1.0, just due to some minimal company
            overhead. Teams and their environments are very different,
            so these are just my generalizations from my work with teams
            over the past three years.

            Anyway, let's say we decide on a drag adjustment of 0.6 for
            our little team on their first sprint. We multiply the
            perfect velocity of 92 ideal days, times 0.6, and we would
            commit to no more than 55 estimated ideal days of backlog
            items for the first sprint.

            The most important thing is that we will learn very quickly
            (guaranteed within 30 days), how many estimated ideal days
            we can really do. We may do 52, or we may do 63, but we'll
            have some feedback to help with sprint two. From this point
            on, the drag factors are not as meaningful, although we can
            reverse calculate them if want.

            If we have to make an initial estimate of an entire release
            (i.e., multiple sprints) without the benefit of having done
            at least one sprint to get real feedback, we have to use an
            estimating method like ideal days and drag adjustments, or
            one of a couple of other variants of estimating. I would
            very strongly recommend trying to do at least one sprint
            before making any long-range commitments for a release. If
            we must do so before starting, be conservative on our drag
            adjustment -- I see way too many new Scrum teams be overly
            optimistic and choose something like 0.8, only to find their
            first sprint is 0.4, and their release average ends up 0.7.

            Does that help?

            Paul
            -----
            Paul Hodgetts -- CEO, Coach, Trainer, Consultant
            phodgetts@... -- (714) 577-5795
            Yahoo agilelogic - AIM AgileLogic - MSN agilelogic - ICQ 295726213

            Agile Logic
            www.agilelogic.com
            1519 E. Chapman Ave. #254 -- Fullerton, CA, USA 92831
            Training, Coaching, Consulting -- Agile Processes/Scrum/Lean/XP
            Complete solutions for adopting agile processes, Scrum and XP.

            Upcoming Events:

            Certified ScrumMaster Training, Las Vegas, NV - April 25-26, 2005
            http://www.agilelogic.com/CSM.html
          • Mike Cohn
            If an ideal day is a day with no distractions and all inputs ready to go when needed by the developer, then if a team is exceeding an ideal day I suspect
            Message 5 of 22 , Mar 7, 2005
              If an ideal day is a day with no distractions and all inputs ready to go
              when needed by the developer, then if a team is exceeding an ideal day I
              suspect they've incorrectly defined an ideal day. It seem impossible to have
              a day with less than zero distractions.

              --Mike Cohn
              Author of User Stories Applied for Agile Software Development
              www.mountaingoatsoftware.com

              -----Original Message-----
              From: Jeff Sutherland [mailto:jeff.sutherland@...]
              Sent: Monday, March 07, 2005 1:53 PM
              To: scrumdevelopment@yahoogroups.com
              Subject: Re: [scrumdevelopment] Velocity?


              It is common for development teams to multiply their ideal developer
              day by a fraction to estimate the amount of work they get done in a
              day. If it is 0.40, they can only allocate 40% of the their day to the
              Sprint backlog.

              It is important for teams to be realistic, particularly in early
              Sprints. The most important thing is to actually complete the work
              they commit to in a Sprint. Once that is done repeatedly, they can
              focus on improving throughput within the Sprint.

              In my view, a 40% team is a very distracted team. I've seen teams run
              at more than 100% of their ideal developer day.

              The reality is that in most organizations a tremendous amount of work
              on blocking items must be undertaken to get teams to peak efficiency.
              That is the hard part of Scrum. The organization must undergo some
              business process reengineering in order for their development teams to
              function properly. People will come up with every reason, however
              improbable, to argue that their teams cannot possibly operate at peak
              efficiency. They will often say that the goal of their organization is
              really not higher productivity.

              They will say this as development jobs are being outsourced because it
              is cheaper to run an inefficient organization elsewhere. The really
              scary thing is that outsourcing organizations are beginning to adopt
              Scrum because it makes them highly competitive.

              Counterintuitively, the more efficiently the team runs, the higher the
              morale.

              Jeff Sutherland


              On Mon, 7 Mar 2005 12:34:42 -0800 (PST), Ravi Srinivasan
              <netlimit2000@...> wrote:
              >
              > Thanks to you all for the prompt response regarding
              > the concept of velocity.
              >
              > I have few more basic questions on velocity.I will
              > pick the definition that helped me best understand
              > what the velocity means:
              >
              > "Velocity is essentially the amount of product
              > completed over time." - Paul Hodgetts
              >
              > Additionally I found this:
              > "The teams with which I've worked multiply their
              > available days times an adjustment of 0.4 to 0.8 to
              > get the number of ideal days they can accomplish, and
              > that helps them figure out their velocity and what
              > they can commit to in a sprint." - Paul Hodgetts
              >
              > Is there any term in SCRUM around the value '0.4'
              > mentioned above? 0.4 (or 40%) is used here as an
              > estimation that will help the team define its
              > velocity.
              > This means that depending on the developer, the factor
              > could be 40% or 80% and still achieve the velocity
              > defined by the team. Right?
              >
              > Thanks
              > Ravi


              To Post a message, send it to: scrumdevelopment@...
              To Unsubscribe, send a blank message to:
              scrumdevelopment-unsubscribe@...
              Yahoo! Groups Links
            • Hubert Smits
              Hi Ravi, I m unsure if Mike Cohn still has the draft of his new book on planning on www.mountaingoatsoftware.com. It is all about planning and very valuable in
              Message 6 of 22 , Mar 8, 2005
                Hi Ravi,

                I'm unsure if Mike Cohn still has the draft of his new book on
                planning on www.mountaingoatsoftware.com. It is all about planning and
                very valuable in answering you questions. Have a look and pick the
                relevant chapter to read.

                My personal opinion: don't go too deep with your studies, once you
                understand the principles of velocity and burndown charts then go with
                your best guess. Planning is an art, not science. And agile planning
                doesn't differ in that respect from any other planning.

                --Hubert


                On Mon, 7 Mar 2005 12:34:42 -0800 (PST), Ravi Srinivasan
                <netlimit2000@...> wrote:
                >
                > Thanks to you all for the prompt response regarding
                > the concept of velocity.
                >
                > I have few more basic questions on velocity…I will
                > pick the definition that helped me best understand
                > what the velocity means:
                >
                > "Velocity is essentially the amount of product
                > completed over time." - Paul Hodgetts
                >
                > Additionally I found this:
                > "The teams with which I've worked multiply their
                > available days times an adjustment of 0.4 to 0.8 to
                > get the number of ideal days they can accomplish, and
                > that helps them figure out their velocity and what
                > they can commit to in a sprint." - Paul Hodgetts
                >
                > Is there any term in SCRUM around the value '0.4'
                > mentioned above? 0.4 (or 40%) is used here as an
                > estimation that will help the team define its
                > velocity.
                > This means that depending on the developer, the factor
                > could be 40% or 80% and still achieve the velocity
                > defined by the team. Right?
                >
                > Thanks
                > Ravi
                >
                > --- Jeff Sutherland <jeff.sutherland@...>
                > wrote:
                > > Well, it may be confusing but it is high school
                > > physics. You know that
                > > about 20% of Americas think that the sun rotates
                > > around the earth and
                > > 45% of Americans think that water coming out of a
                > > coiled hose will
                > > flow in a spiral fashion. Not to mention another 45%
                > > that think a ball
                > > rolling off a table top will hit the floor directly
                > > below the edge of
                > > the table. An equal number think the earth was
                > > created about 4000
                > > years ago, but I digress.
                > >
                > > Velocity equals the rate of change of distance with
                > > time. Acceleration
                > > is the rate of change of velocity. This has nothing
                > > to do with Scrum.
                > >
                > > In Scrum, the distance is amount of work done.
                > >
                > > However, we train people in CSM to use an ideal
                > > developer day to
                > > estimate work for their team. This concept of an
                > > ideal developer day
                > > will be different for different Scrum teams. Ergo,
                > > productivity can be
                > > different across teams with the same velocity.
                > >
                > > I don't see any new jargon here. We have been using
                > > the same words for a decade.
                > >
                > > Jeff Sutherland
                > >
                > >
                > > On Sun, 6 Mar 2005 11:36:48 -0800, Phlip
                > > <phlip2005@...> wrote:
                > > >
                > > > Jeff Sutherland wrote:
                > > >
                > > > > Velocity is the rate of change of the burndown
                > > chart. Ideally, the
                > > > > burndown drops one day per team member every
                > > day.
                > > >
                > > > This answer doubles the amount of undefined
                > > jargon, and then adds a
                > > > confusing ideal that implies one can _set_ the
                > > velocity.
                > > >
                > > > Who do you think you are?
                > > >
                > > > Oh, wait. You think you are Jeff Sutherland.
                > > >
                > > > <impersonation voice="Emily Litela">Never
                > > mind.</impersonation>
                > > >
                > > > --
                > > > Phlip
                > > >
                > >
                > http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
                > >
                >
                > __________________________________
                > Celebrate Yahoo!'s 10th Birthday!
                > Yahoo! Netrospective: 100 Moments of the Web
                > http://birthday.yahoo.com/netrospective/
                >
                > To Post a message, send it to: scrumdevelopment@...
                > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
                > Yahoo! Groups Links
                >
                >
                >
                >
                >
              • Jeff Sutherland
                When a basketball team enters the zone they score more points than their ideal day. Records are set. Jeff On Mon, 7 Mar 2005 18:57:37 -0700, Mike Cohn
                Message 7 of 22 , Mar 8, 2005
                  When a basketball team enters the "zone" they score more points than
                  their ideal day. Records are set.

                  Jeff


                  On Mon, 7 Mar 2005 18:57:37 -0700, Mike Cohn
                  <mike@...> wrote:
                  >
                  > If an ideal day is a day with no distractions and all inputs ready to go
                  > when needed by the developer, then if a team is exceeding an ideal day I
                  > suspect they've incorrectly defined an ideal day. It seem impossible to have
                  > a day with less than zero distractions.
                  >
                  > --Mike Cohn
                  > Author of User Stories Applied for Agile Software Development
                  > www.mountaingoatsoftware.com
                  >
                  > -----Original Message-----
                  > From: Jeff Sutherland [mailto:jeff.sutherland@...]
                  > Sent: Monday, March 07, 2005 1:53 PM
                  > To: scrumdevelopment@yahoogroups.com
                  > Subject: Re: [scrumdevelopment] Velocity?
                  >
                  > It is common for development teams to multiply their ideal developer
                  > day by a fraction to estimate the amount of work they get done in a
                  > day. If it is 0.40, they can only allocate 40% of the their day to the
                  > Sprint backlog.
                  >
                  > It is important for teams to be realistic, particularly in early
                  > Sprints. The most important thing is to actually complete the work
                  > they commit to in a Sprint. Once that is done repeatedly, they can
                  > focus on improving throughput within the Sprint.
                  >
                  > In my view, a 40% team is a very distracted team. I've seen teams run
                  > at more than 100% of their ideal developer day.
                  >
                  > The reality is that in most organizations a tremendous amount of work
                  > on blocking items must be undertaken to get teams to peak efficiency.
                  > That is the hard part of Scrum. The organization must undergo some
                  > business process reengineering in order for their development teams to
                  > function properly. People will come up with every reason, however
                  > improbable, to argue that their teams cannot possibly operate at peak
                  > efficiency. They will often say that the goal of their organization is
                  > really not higher productivity.
                  >
                  > They will say this as development jobs are being outsourced because it
                  > is cheaper to run an inefficient organization elsewhere. The really
                  > scary thing is that outsourcing organizations are beginning to adopt
                  > Scrum because it makes them highly competitive.
                  >
                  > Counterintuitively, the more efficiently the team runs, the higher the
                  > morale.
                  >
                  > Jeff Sutherland
                  >
                  > On Mon, 7 Mar 2005 12:34:42 -0800 (PST), Ravi Srinivasan
                  > <netlimit2000@...> wrote:
                  > >
                  > > Thanks to you all for the prompt response regarding
                  > > the concept of velocity.
                  > >
                  > > I have few more basic questions on velocity.I will
                  > > pick the definition that helped me best understand
                  > > what the velocity means:
                  > >
                  > > "Velocity is essentially the amount of product
                  > > completed over time." - Paul Hodgetts
                  > >
                  > > Additionally I found this:
                  > > "The teams with which I've worked multiply their
                  > > available days times an adjustment of 0.4 to 0.8 to
                  > > get the number of ideal days they can accomplish, and
                  > > that helps them figure out their velocity and what
                  > > they can commit to in a sprint." - Paul Hodgetts
                  > >
                  > > Is there any term in SCRUM around the value '0.4'
                  > > mentioned above? 0.4 (or 40%) is used here as an
                  > > estimation that will help the team define its
                  > > velocity.
                  > > This means that depending on the developer, the factor
                  > > could be 40% or 80% and still achieve the velocity
                  > > defined by the team. Right?
                  > >
                  > > Thanks
                  > > Ravi
                  >
                  > To Post a message, send it to: scrumdevelopment@...
                  > To Unsubscribe, send a blank message to:
                  > scrumdevelopment-unsubscribe@...
                  > Yahoo! Groups Links
                  >
                  > To Post a message, send it to: scrumdevelopment@...
                  > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
                  > Yahoo! Groups Links
                  >
                  >
                  >
                • Mike Cohn
                  But if a basketball team were to define an ideal game it would probably be one where all shots went in or when all defenders were out of place. My point is
                  Message 8 of 22 , Mar 8, 2005
                    But if a basketball team were to define an ideal game it would probably be
                    one where all shots went in or when all defenders were out of place.

                    My point is that if it is something a team can do then it's not their
                    ideal--there must be some overhead, there must be some missed shots.

                    --Mike

                    -----Original Message-----
                    From: Jeff Sutherland [mailto:jeff.sutherland@...]
                    Sent: Tuesday, March 08, 2005 7:21 AM
                    To: scrumdevelopment@yahoogroups.com
                    Subject: Re: [scrumdevelopment] Velocity?


                    When a basketball team enters the "zone" they score more points than
                    their ideal day. Records are set.

                    Jeff


                    On Mon, 7 Mar 2005 18:57:37 -0700, Mike Cohn
                    <mike@...> wrote:
                    >
                    > If an ideal day is a day with no distractions and all inputs ready to go
                    > when needed by the developer, then if a team is exceeding an ideal day I
                    > suspect they've incorrectly defined an ideal day. It seem impossible to
                    have
                    > a day with less than zero distractions.
                    >
                    > --Mike Cohn
                    > Author of User Stories Applied for Agile Software Development
                    > www.mountaingoatsoftware.com
                    >
                    > -----Original Message-----
                    > From: Jeff Sutherland [mailto:jeff.sutherland@...]
                    > Sent: Monday, March 07, 2005 1:53 PM
                    > To: scrumdevelopment@yahoogroups.com
                    > Subject: Re: [scrumdevelopment] Velocity?
                    >
                    > It is common for development teams to multiply their ideal developer
                    > day by a fraction to estimate the amount of work they get done in a
                    > day. If it is 0.40, they can only allocate 40% of the their day to the
                    > Sprint backlog.
                    >
                    > It is important for teams to be realistic, particularly in early
                    > Sprints. The most important thing is to actually complete the work
                    > they commit to in a Sprint. Once that is done repeatedly, they can
                    > focus on improving throughput within the Sprint.
                    >
                    > In my view, a 40% team is a very distracted team. I've seen teams run
                    > at more than 100% of their ideal developer day.
                    >
                    > The reality is that in most organizations a tremendous amount of work
                    > on blocking items must be undertaken to get teams to peak efficiency.
                    > That is the hard part of Scrum. The organization must undergo some
                    > business process reengineering in order for their development teams to
                    > function properly. People will come up with every reason, however
                    > improbable, to argue that their teams cannot possibly operate at peak
                    > efficiency. They will often say that the goal of their organization is
                    > really not higher productivity.
                    >
                    > They will say this as development jobs are being outsourced because it
                    > is cheaper to run an inefficient organization elsewhere. The really
                    > scary thing is that outsourcing organizations are beginning to adopt
                    > Scrum because it makes them highly competitive.
                    >
                    > Counterintuitively, the more efficiently the team runs, the higher the
                    > morale.
                    >
                    > Jeff Sutherland
                    >
                    > On Mon, 7 Mar 2005 12:34:42 -0800 (PST), Ravi Srinivasan
                    > <netlimit2000@...> wrote:
                    > >
                    > > Thanks to you all for the prompt response regarding
                    > > the concept of velocity.
                    > >
                    > > I have few more basic questions on velocity.I will
                    > > pick the definition that helped me best understand
                    > > what the velocity means:
                    > >
                    > > "Velocity is essentially the amount of product
                    > > completed over time." - Paul Hodgetts
                    > >
                    > > Additionally I found this:
                    > > "The teams with which I've worked multiply their
                    > > available days times an adjustment of 0.4 to 0.8 to
                    > > get the number of ideal days they can accomplish, and
                    > > that helps them figure out their velocity and what
                    > > they can commit to in a sprint." - Paul Hodgetts
                    > >
                    > > Is there any term in SCRUM around the value '0.4'
                    > > mentioned above? 0.4 (or 40%) is used here as an
                    > > estimation that will help the team define its
                    > > velocity.
                    > > This means that depending on the developer, the factor
                    > > could be 40% or 80% and still achieve the velocity
                    > > defined by the team. Right?
                    > >
                    > > Thanks
                    > > Ravi
                    >
                    > To Post a message, send it to: scrumdevelopment@...
                    > To Unsubscribe, send a blank message to:
                    > scrumdevelopment-unsubscribe@...
                    > Yahoo! Groups Links
                    >
                    > To Post a message, send it to: scrumdevelopment@...
                    > To Unsubscribe, send a blank message to:
                    scrumdevelopment-unsubscribe@...
                    > Yahoo! Groups Links
                    >
                    >
                    >


                    To Post a message, send it to: scrumdevelopment@...
                    To Unsubscribe, send a blank message to:
                    scrumdevelopment-unsubscribe@...
                    Yahoo! Groups Links
                  • Mike Cohn
                    Yes, there are chapters for an upcoming book called Agile Estimating and Planning at www.mountaingoatsoftware.com/agileplanning. There used to be more
                    Message 9 of 22 , Mar 8, 2005
                      Yes, there are chapters for an upcoming book called "Agile Estimating and
                      Planning" at www.mountaingoatsoftware.com/agileplanning. There used to be
                      more chapters up there but I'm working on second drafts so I'm only
                      reposting chapters as I finish second drafts. I'd love to hear thoughts on
                      the available chapters from anyone interesting in estimating and planning.

                      Thanks,
                      Mike Cohn
                      Author of User Stories Applied for Agile Software Development
                      www.mountaingoatsoftware.com

                      -----Original Message-----
                      From: Hubert Smits [mailto:hubert.smits@...]
                      Sent: Tuesday, March 08, 2005 1:42 AM
                      To: scrumdevelopment@yahoogroups.com
                      Subject: Re: [scrumdevelopment] Velocity?


                      Hi Ravi,

                      I'm unsure if Mike Cohn still has the draft of his new book on
                      planning on www.mountaingoatsoftware.com. It is all about planning and
                      very valuable in answering you questions. Have a look and pick the
                      relevant chapter to read.

                      My personal opinion: don't go too deep with your studies, once you
                      understand the principles of velocity and burndown charts then go with
                      your best guess. Planning is an art, not science. And agile planning
                      doesn't differ in that respect from any other planning.

                      --Hubert


                      On Mon, 7 Mar 2005 12:34:42 -0800 (PST), Ravi Srinivasan
                      <netlimit2000@...> wrote:
                      >
                      > Thanks to you all for the prompt response regarding
                      > the concept of velocity.
                      >
                      > I have few more basic questions on velocity.I will
                      > pick the definition that helped me best understand
                      > what the velocity means:
                      >
                      > "Velocity is essentially the amount of product
                      > completed over time." - Paul Hodgetts
                      >
                      > Additionally I found this:
                      > "The teams with which I've worked multiply their
                      > available days times an adjustment of 0.4 to 0.8 to
                      > get the number of ideal days they can accomplish, and
                      > that helps them figure out their velocity and what
                      > they can commit to in a sprint." - Paul Hodgetts
                      >
                      > Is there any term in SCRUM around the value '0.4'
                      > mentioned above? 0.4 (or 40%) is used here as an
                      > estimation that will help the team define its
                      > velocity.
                      > This means that depending on the developer, the factor
                      > could be 40% or 80% and still achieve the velocity
                      > defined by the team. Right?
                      >
                      > Thanks
                      > Ravi
                      >
                      > --- Jeff Sutherland <jeff.sutherland@...>
                      > wrote:
                      > > Well, it may be confusing but it is high school
                      > > physics. You know that
                      > > about 20% of Americas think that the sun rotates
                      > > around the earth and
                      > > 45% of Americans think that water coming out of a
                      > > coiled hose will
                      > > flow in a spiral fashion. Not to mention another 45%
                      > > that think a ball
                      > > rolling off a table top will hit the floor directly
                      > > below the edge of
                      > > the table. An equal number think the earth was
                      > > created about 4000
                      > > years ago, but I digress.
                      > >
                      > > Velocity equals the rate of change of distance with
                      > > time. Acceleration
                      > > is the rate of change of velocity. This has nothing
                      > > to do with Scrum.
                      > >
                      > > In Scrum, the distance is amount of work done.
                      > >
                      > > However, we train people in CSM to use an ideal
                      > > developer day to
                      > > estimate work for their team. This concept of an
                      > > ideal developer day
                      > > will be different for different Scrum teams. Ergo,
                      > > productivity can be
                      > > different across teams with the same velocity.
                      > >
                      > > I don't see any new jargon here. We have been using
                      > > the same words for a decade.
                      > >
                      > > Jeff Sutherland
                      > >
                      > >
                      > > On Sun, 6 Mar 2005 11:36:48 -0800, Phlip
                      > > <phlip2005@...> wrote:
                      > > >
                      > > > Jeff Sutherland wrote:
                      > > >
                      > > > > Velocity is the rate of change of the burndown
                      > > chart. Ideally, the
                      > > > > burndown drops one day per team member every
                      > > day.
                      > > >
                      > > > This answer doubles the amount of undefined
                      > > jargon, and then adds a
                      > > > confusing ideal that implies one can _set_ the
                      > > velocity.
                      > > >
                      > > > Who do you think you are?
                      > > >
                      > > > Oh, wait. You think you are Jeff Sutherland.
                      > > >
                      > > > <impersonation voice="Emily Litela">Never
                      > > mind.</impersonation>
                      > > >
                      > > > --
                      > > > Phlip
                      > > >
                      > >
                      > http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
                      > >
                      >
                      > __________________________________
                      > Celebrate Yahoo!'s 10th Birthday!
                      > Yahoo! Netrospective: 100 Moments of the Web
                      > http://birthday.yahoo.com/netrospective/
                      >
                      > To Post a message, send it to: scrumdevelopment@...
                      > To Unsubscribe, send a blank message to:
                      scrumdevelopment-unsubscribe@...
                      > Yahoo! Groups Links
                      >
                      >
                      >
                      >
                      >


                      To Post a message, send it to: scrumdevelopment@...
                      To Unsubscribe, send a blank message to:
                      scrumdevelopment-unsubscribe@...
                      Yahoo! Groups Links
                    Your message has been successfully submitted and would be delivered to recipients shortly.