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

Re: [scrumdevelopment] Re: Conservation of Size Points, AKA: Partial Credit for Backlogs

Expand Messages
  • Jayanthan Bhattathiripad
    I agree with you, Mark. I am not sure if the overhead of splitting stories and then calculating the balance is worth the effort. Its easier to communicate the
    Message 1 of 17 , Apr 1, 2009
      I agree with you, Mark. I am not sure if the overhead of splitting
      stories and then calculating the balance is worth the effort. Its easier
      to communicate the progress for even those stories not done using words
      than numbers.

      Jayanthan

      woynam wrote:
      >
      >
      > We elected 'b', and it worked fine. Sure, you don't get a "true"
      > velocity, but velocity itself is a means to an end, not the goal of
      > using story points.
      >
      > I found it better to use a rolling average (3 iterations) when
      > calculating velocity. In general, there was always stories that
      > weren't quite finished, and were credited in the next iteration. Also,
      > using a rolling average helps smooth out the hills and valleys, and
      > IMHO, gives a more accurate measure of the speed of the team.
      >
      > Mark
      >
      > --- In scrumdevelopment@yahoogroups.com
      > <mailto:scrumdevelopment%40yahoogroups.com>, "steveteske"
      > <steveteske@...> wrote:
      > >
      > > We are having a lively debate about Size Points. I am calling the
      > "Conservation of Size Points Debate", because the following practices
      > of your SCRUM Masters:
      > >
      > > Either a) If you don't finish a backlog item, estimate the remaining
      > size of the backlog and assign it to the next sprint, giving partial
      > credit to the failing sprint (thus preserving the overall size points)
      > >
      > > or b) If you don't finish a backlog item, give yourself zero credit
      > in the failing sprint and carry over the size points (without
      > reduction) to the next sprint. When you actual finish the backlog, you
      > get count credit for in the sprint in which it is finished...but it's
      > full credit from the original size points (don't reduce).
      > >
      > > Mathematically these two paradigms result in EXACTLY the same
      > velocity calculation.
      > >
      > > Here's my dilema: I think the math above does not reflect true
      > velocity. I don't have a palatable explanation of why partial credit
      > schemes will fail to delivery the correct velocity measurement. But
      > the harder isssue is the politics of counting instantaneous velocity
      > (counting only the things that are DONE) and discarding the size
      > points of partially completed work appears to reduce the overall
      > backlog size. It appears that size points are disappearing if I count
      > only the "Done" work. While I believe this promotes a better
      > understanding of TRUE velocity, the politics and the Math of what I
      > call non-conservation of size points is apparently either my
      > misunderstanding of SCRUM or it's a bridge too far for my director to
      > sell to Project Management because in non-conservation of size points,
      > it looks like size points are mysteriously disappearing.
      > >
      > > I don't have a problem with disappearing size points because
      > according to my math, if I have TRUE velocity and the total size
      > points to the next release, I've got what I need.
      > >
      > > I am not sure how to deal with conservation vs. non-conservation of
      > size points.
      > >
      > > Help would be appreciated.
      > >
      > > Steve Teske
      > > Thales Communications Inc., Clarksburg, MD
      > >
      >
      >
    • mike.dwyer1@comcast.net
      Then why do all this work and then cop out at the end. Stay with conventional practices folks. We need people with this kind of thinking to not consider
      Message 2 of 17 , Apr 1, 2009
        Then why do all this work and then cop out at the end. Stay with conventional practices folks. We need people with this kind of thinking to not consider themselves part of this community.
        Agile and Scrum are about done. AIG and other loser approaches about rewarding whining and in doing so ripping off this country and this world.
        Yes it hard work and not much fun. Most of all you have to lose to be successful. That is a lot better than what you are suggesting.

        Sent via BlackBerry by AT&T


        From: Jayanthan Bhattathiripad
        Date: Wed, 01 Apr 2009 12:36:00 -0400
        To: <scrumdevelopment@yahoogroups.com>
        Subject: Re: [scrumdevelopment] Re: Conservation of Size Points, AKA: Partial Credit for Backlogs

        I agree with you, Mark. I am not sure if the overhead of splitting
        stories and then calculating the balance is worth the effort. Its easier
        to communicate the progress for even those stories not done using words
        than numbers.

        Jayanthan

        woynam wrote:

        >
        >
        > We elected 'b', and it worked fine. Sure, you don't get a "true"
        > velocity, but velocity itself is a means to an end, not the goal of
        > using story points.
        >
        > I found it better to use a rolling average (3 iterations) when
        > calculating velocity. In general, there was always stories that
        > weren't quite finished, and were credited in the next iteration. Also,
        > using a rolling average helps smooth out the hills and valleys, and
        > IMHO, gives a more accurate measure of the speed of the team.
        >
        > Mark
        >
        > --- In scrumdevelopment@ yahoogroups. com
        > <mailto:scrumdevelo pment%40yahoogro ups.com>, "steveteske"
        > <steveteske@ ...> wrote:
        > >
        > > We are having a lively debate about Size Points. I am calling the
        > "Conservation of Size Points Debate", because the following practices
        > of your SCRUM Masters:
        > >
        > > Either a) If you don't finish a backlog item, estimate the remaining
        > size of the backlog and assign it to the next sprint, giving partial
        > credit to the failing sprint (thus preserving the overall size points)
        > >
        > > or b) If you don't finish a backlog item, give yourself zero credit
        > in the failing sprint and carry over the size points (without
        > reduction) to the next sprint. When you actual finish the backlog, you
        > get count credit for in the sprint in which it is finished...but it's
        > full credit from the original size points (don't reduce).
        > >
        > > Mathematically these two paradigms result in EXACTLY the same
        > velocity calculation.
        > >
        > > Here's my dilema: I think the math above does not reflect true
        > velocity. I don't have a palatable explanation of why partial credit
        > schemes will fail to delivery the correct velocity measurement. But
        > the harder isssue is the politics of counting instantaneous velocity
        > (counting only the things that are DONE) and discarding the size
        > points of partially completed work appears to reduce the overall
        > backlog size. It appears that size points are disappearing if I count
        > only the "Done" work. While I believe this promotes a better
        > understanding of TRUE velocity, the politics and the Math of what I
        > call non-conservation of size points is apparently either my
        > misunderstanding of SCRUM or it's a bridge too far for my director to
        > sell to Project Management because in non-conservation of size points,
        > it looks like size points are mysteriously disappearing.
        > >
        > > I don't have a problem with disappearing size points because
        > according to my math, if I have TRUE velocity and the total size
        > points to the next release, I've got what I need.
        > >
        > > I am not sure how to deal with conservation vs. non-conservation of
        > size points.
        > >
        > > Help would be appreciated.
        > >
        > > Steve Teske
        > > Thales Communications Inc., Clarksburg, MD
        > >
        >
        >

      • woynam
        Mike, what on earth are you talking about? I have no idea if you agree or disagree with our comments. Mark
        Message 3 of 17 , Apr 1, 2009
          Mike, what on earth are you talking about? I have no idea if you agree or disagree with our comments.

          Mark

          --- In scrumdevelopment@yahoogroups.com, mike.dwyer1@... wrote:
          >
          > Then why do all this work and then cop out at the end. Stay with conventional practices folks. We need people with this kind of thinking to not consider themselves part of this community.
          > Agile and Scrum are about done. AIG and other loser approaches about rewarding whining and in doing so ripping off this country and this world.
          > Yes it hard work and not much fun. Most of all you have to lose to be successful. That is a lot better than what you are suggesting.
          >
          >
          > Sent via BlackBerry by AT&T
          >
          > -----Original Message-----
          > From: Jayanthan Bhattathiripad <jynthn@...>
          >
          > Date: Wed, 01 Apr 2009 12:36:00
          > To: <scrumdevelopment@yahoogroups.com>
          > Subject: Re: [scrumdevelopment] Re: Conservation of Size Points, AKA: Partial
          > Credit for Backlogs
          >
          >
          > I agree with you, Mark. I am not sure if the overhead of splitting
          > stories and then calculating the balance is worth the effort. Its easier
          > to communicate the progress for even those stories not done using words
          > than numbers.
          >
          > Jayanthan
          >
          > woynam wrote:
          > >
          > >
          > > We elected 'b', and it worked fine. Sure, you don't get a "true"
          > > velocity, but velocity itself is a means to an end, not the goal of
          > > using story points.
          > >
          > > I found it better to use a rolling average (3 iterations) when
          > > calculating velocity. In general, there was always stories that
          > > weren't quite finished, and were credited in the next iteration. Also,
          > > using a rolling average helps smooth out the hills and valleys, and
          > > IMHO, gives a more accurate measure of the speed of the team.
          > >
          > > Mark
          > >
          > > --- In scrumdevelopment@yahoogroups.com
          > > <mailto:scrumdevelopment%40yahoogroups.com>, "steveteske"
          > > <steveteske@> wrote:
          > > >
          > > > We are having a lively debate about Size Points. I am calling the
          > > "Conservation of Size Points Debate", because the following practices
          > > of your SCRUM Masters:
          > > >
          > > > Either a) If you don't finish a backlog item, estimate the remaining
          > > size of the backlog and assign it to the next sprint, giving partial
          > > credit to the failing sprint (thus preserving the overall size points)
          > > >
          > > > or b) If you don't finish a backlog item, give yourself zero credit
          > > in the failing sprint and carry over the size points (without
          > > reduction) to the next sprint. When you actual finish the backlog, you
          > > get count credit for in the sprint in which it is finished...but it's
          > > full credit from the original size points (don't reduce).
          > > >
          > > > Mathematically these two paradigms result in EXACTLY the same
          > > velocity calculation.
          > > >
          > > > Here's my dilema: I think the math above does not reflect true
          > > velocity. I don't have a palatable explanation of why partial credit
          > > schemes will fail to delivery the correct velocity measurement. But
          > > the harder isssue is the politics of counting instantaneous velocity
          > > (counting only the things that are DONE) and discarding the size
          > > points of partially completed work appears to reduce the overall
          > > backlog size. It appears that size points are disappearing if I count
          > > only the "Done" work. While I believe this promotes a better
          > > understanding of TRUE velocity, the politics and the Math of what I
          > > call non-conservation of size points is apparently either my
          > > misunderstanding of SCRUM or it's a bridge too far for my director to
          > > sell to Project Management because in non-conservation of size points,
          > > it looks like size points are mysteriously disappearing.
          > > >
          > > > I don't have a problem with disappearing size points because
          > > according to my math, if I have TRUE velocity and the total size
          > > points to the next release, I've got what I need.
          > > >
          > > > I am not sure how to deal with conservation vs. non-conservation of
          > > size points.
          > > >
          > > > Help would be appreciated.
          > > >
          > > > Steve Teske
          > > > Thales Communications Inc., Clarksburg, MD
          > > >
          > >
          > >
          >
        • Adam Sroka
          ... Right. What some, including myself, have advocated is that you size up the remaining work and give zero credit for work in the current iteration that was
          Message 4 of 17 , Apr 1, 2009
            On Tue, Mar 31, 2009 at 6:39 PM, steveteske <steveteske@...> wrote:
            > We are having a lively debate about Size Points. I am calling the
            > "Conservation of Size Points Debate", because the following practices of
            > your SCRUM Masters:
            >
            > Either a) If you don't finish a backlog item, estimate the remaining size of
            > the backlog and assign it to the next sprint, giving partial credit to the
            > failing sprint (thus preserving the overall size points)
            >
            > or b) If you don't finish a backlog item, give yourself zero credit in the
            > failing sprint and carry over the size points (without reduction) to the
            > next sprint. When you actual finish the backlog, you get count credit for in
            > the sprint in which it is finished...but it's full credit from the original
            > size points (don't reduce).
            >
            > Mathematically these two paradigms result in EXACTLY the same velocity
            > calculation.
            >
            > Here's my dilema: I think the math above does not reflect true velocity. I
            > don't have a palatable explanation of why partial credit schemes will fail
            > to delivery the correct velocity measurement.

            Right. What some, including myself, have advocated is that you size up
            the remaining work and give zero credit for work in the current
            iteration that was not completed. In this way you somewhat
            underestimate the actual effort that was expended, but you account for
            the fact that some of that effort was wasted (in the sense that
            whatever was produced was not deliverable at the end of the
            iteration.)

            This is not conservative of points. Points are arbitrary by
            definition. So, not conserving them doesn't hurt me one bit.

            This approach makes all kinds of sense to me. I am a musician. Also, I
            practice martial arts. In both of those avocations we strive to
            perform accurately and fast. In order to go fast we have to push
            ourselves. There will always be a speed that is too fast for us to
            perform accurately. So, we slow down to the point where we are
            accurate again and gradually increase our speed.

            What I am saying is that missing a story is like missing a note. The
            correct response is to slow down and stop missing them. Then speed up
            again.

            But the harder isssue is the
            > politics of counting instantaneous velocity (counting only the things that
            > are DONE) and discarding the size points of partially completed work appears
            > to reduce the overall backlog size. It appears that size points are
            > disappearing if I count only the "Done" work. While I believe this promotes
            > a better understanding of TRUE velocity, the politics and the Math of what I
            > call non-conservation of size points is apparently either my
            > misunderstanding of SCRUM or it's a bridge too far for my director to sell
            > to Project Management because in non-conservation of size points, it looks
            > like size points are mysteriously disappearing.
            >
            > I don't have a problem with disappearing size points because according to my
            > math, if I have TRUE velocity and the total size points to the next release,
            > I've got what I need.
            >
            > I am not sure how to deal with conservation vs. non-conservation of size
            > points.
            >

            I would tell them that the missing points represent waste. Effort was
            expended that did not result in any story being delivered and that
            effort does not count. The re-estimate of the story accounts for the
            amount of effort it will take to recoup that loss. Since you aren't
            going to redo anything you already did, the new cost is not as high.

            I would also point out that story points are arbitrary and there is no
            reason to believe that they are conservative. If that doesn't go over,
            I would point out that effort is conservative in the same way that
            energy is: we know that the sum of the energy in equals the sum of the
            energy out. We also know that only a portion (Often a very small
            portion) of that energy produces work. Our velocity in Scrum is a
            measure of the work we produced in the iteration, not of the total
            effort that went in.

            In other words:

            Total Effort = Effort that produced running tested software + Waste

            Velocity = Effort that produced running tested software *during the iteration*
          • mike.dwyer1@comcast.net
            I took this to be a 4/1 post. Sorry But since you are serious on this, let s ask some simple questions. Is this preoccupation with the math of story points
            Message 5 of 17 , Apr 1, 2009
              I took this to be a 4/1 post. Sorry

              But since you are serious on this, let's ask some simple questions.
              Is this preoccupation with the math of story points clouding the actual value they bring? Keep in mind that velocity is nothing more than a regression to the mean and since we choose not to keep teams together long enough for it to have any statistical relevance. If your projects are over in 6 - 12 months 8 - 24 samples are useless in a linear regression. Now if we want to think in trends that is another story and another slope to slide on.
              But trends are estimates and that is it they don't go any where else

              So what can a story sizing do? Hmm create a collaborative and self correcting map of the capability to deliver value. If you suck at doing that then you need to find this out and do something about.
              Focusing on giving yourself credit doesn't make that happen. Try spending time on why you can't estimate

              Sent via BlackBerry by AT&T


              From: "woynam"
              Date: Wed, 01 Apr 2009 20:03:47 -0000
              To: <scrumdevelopment@yahoogroups.com>
              Subject: [scrumdevelopment] Re: Conservation of Size Points, AKA: PartialCredit for Backlogs


              Mike, what on earth are you talking about? I have no idea if you agree or disagree with our comments.

              Mark

              --- In scrumdevelopment@ yahoogroups. com, mike.dwyer1@ ... wrote:
              >
              > Then why do all this work and then cop out at the end. Stay with conventional practices folks. We need people with this kind of thinking to not consider themselves part of this community.
              > Agile and Scrum are about done. AIG and other loser approaches about rewarding whining and in doing so ripping off this country and this world.
              > Yes it hard work and not much fun. Most of all you have to lose to be successful. That is a lot better than what you are suggesting.
              >
              >
              > Sent via BlackBerry by AT&T
              >
              > -----Original Message-----
              > From: Jayanthan Bhattathiripad <jynthn@...>
              >
              > Date: Wed, 01 Apr 2009 12:36:00
              > To: <scrumdevelopment@ yahoogroups. com>
              > Subject: Re: [scrumdevelopment] Re: Conservation of Size Points, AKA: Partial
              > Credit for Backlogs
              >
              >
              > I agree with you, Mark. I am not sure if the overhead of splitting
              > stories and then calculating the balance is worth the effort. Its easier
              > to communicate the progress for even those stories not done using words
              > than numbers.
              >
              > Jayanthan
              >
              > woynam wrote:
              > >
              > >
              > > We elected 'b', and it worked fine. Sure, you don't get a "true"
              > > velocity, but velocity itself is a means to an end, not the goal of
              > > using story points.
              > >
              > > I found it better to use a rolling average (3 iterations) when
              > > calculating velocity. In general, there was always stories that
              > > weren't quite finished, and were credited in the next iteration. Also,
              > > using a rolling average helps smooth out the hills and valleys, and
              > > IMHO, gives a more accurate measure of the speed of the team.
              > >
              > > Mark
              > >
              > > --- In scrumdevelopment@ yahoogroups. com
              > > <mailto:scrumdevelo pment%40yahoogro ups.com>, "steveteske"
              > > <steveteske@ > wrote:
              > > >
              > > > We are having a lively debate about Size Points. I am calling the
              > > "Conservation of Size Points Debate", because the following practices
              > > of your SCRUM Masters:
              > > >
              > > > Either a) If you don't finish a backlog item, estimate the remaining
              > > size of the backlog and assign it to the next sprint, giving partial
              > > credit to the failing sprint (thus preserving the overall size points)
              > > >
              > > > or b) If you don't finish a backlog item, give yourself zero credit
              > > in the failing sprint and carry over the size points (without
              > > reduction) to the next sprint. When you actual finish the backlog, you
              > > get count credit for in the sprint in which it is finished...but it's
              > > full credit from the original size points (don't reduce).
              > > >
              > > > Mathematically these two paradigms result in EXACTLY the same
              > > velocity calculation.
              > > >
              > > > Here's my dilema: I think the math above does not reflect true
              > > velocity. I don't have a palatable explanation of why partial credit
              > > schemes will fail to delivery the correct velocity measurement. But
              > > the harder isssue is the politics of counting instantaneous velocity
              > > (counting only the things that are DONE) and discarding the size
              > > points of partially completed work appears to reduce the overall
              > > backlog size. It appears that size points are disappearing if I count
              > > only the "Done" work. While I believe this promotes a better
              > > understanding of TRUE velocity, the politics and the Math of what I
              > > call non-conservation of size points is apparently either my
              > > misunderstanding of SCRUM or it's a bridge too far for my director to
              > > sell to Project Management because in non-conservation of size points,
              > > it looks like size points are mysteriously disappearing.
              > > >
              > > > I don't have a problem with disappearing size points because
              > > according to my math, if I have TRUE velocity and the total size
              > > points to the next release, I've got what I need.
              > > >
              > > > I am not sure how to deal with conservation vs. non-conservation of
              > > size points.
              > > >
              > > > Help would be appreciated.
              > > >
              > > > Steve Teske
              > > > Thales Communications Inc., Clarksburg, MD
              > > >
              > >
              > >
              >

            • George Dinwiddie
              ... Steve, I was traveling yesterday and see you ve already received a lot of good replies. I d like to approach this in a slightly different fashion, though
              Message 6 of 17 , Apr 2, 2009
                Steve Teske wrote:
                > We are having a lively debate about Size Points...
                >
                > ...giving partial
                > credit to the failing sprint
                >
                > ...give yourself zero credit
                > in the failing sprint and carry over...
                > ...full credit from the original size points (don't reduce).
                >
                > Mathematically these two paradigms result in EXACTLY the same
                > velocity calculation.
                >
                > Here's my dilema: I think the math above does not reflect true
                > velocity. I don't have a palatable explanation of why partial credit
                > schemes will fail to delivery the correct velocity measurement. But
                > the harder isssue is the politics of counting instantaneous velocity
                > (counting only the things that are DONE) and discarding the size
                > points of partially completed work appears to reduce the overall
                > backlog size. It appears that size points are disappearing if I
                > count only the "Done" work. While I believe this promotes a better
                > understanding of TRUE velocity, the politics and the Math of what I
                > call non-conservation of size points is apparently either my
                > misunderstanding of SCRUM or it's a bridge too far for my director to
                > sell to Project Management because in non-conservation of size
                > points, it looks like size points are mysteriously disappearing.

                Steve, I was traveling yesterday and see you've already received a lot
                of good replies. I'd like to approach this in a slightly different
                fashion, though others have hinted in this direction.

                Why does your organization give so much importance to story points? Why
                do you think they're a credit to the team? Why does your Project
                Management think they're something to put in the bank?

                What is your goal? To produce valuable, working software? Or to
                collect story points?

                Why do you use story points? To measure the worth of the team? Or to
                help the team select approximately the right amount of work for the next
                iteration?

                - George

                --
                ----------------------------------------------------------------------
                * George Dinwiddie * http://blog.gdinwiddie.com
                Software Development http://www.idiacomputing.com
                Consultant and Coach http://www.agilemaryland.org
                ----------------------------------------------------------------------
              • Roy Morien
                You seem to be trying to make a mathematical science out of a simple concept used for a simple purpose. The complexity about story points is being able to
                Message 7 of 17 , Apr 2, 2009
                  You seem to be trying to make a mathematical science out of a simple concept used for a simple purpose. The complexity about story points is being able to first decide on your scale, and then assessing user stories for their story point value.That takes experience and gut feeling, frankly. Even if you get awfully good at it, it is still only indicative and approximate.
                   
                  If you try to use story points for any other reason (which is to estimate story complexity and probable effort , and apply that to an estimate of probable completion dates) then you will introduce a whole raft of nonsense and 'cheating' into it. Eg, if a manager starts to compare across teams based on story points achieved, then, simple solution to stay ahead of the other team, move your scale up ... what was a 4 point story is now an 8 point story, on no other grounds but you have changed your scale.
                   
                  I see this aas yet another outside cause of why agile methods 'fail', not for any intrinsic weakness or problem in the method, but because of outside misuse and misunderstanding.
                   
                  Regards,
                  Roy Morien
                   

                  To: scrumdevelopment@yahoogroups.com
                  From: lists@...
                  Date: Thu, 2 Apr 2009 08:00:55 -0400
                  Subject: Re: [scrumdevelopment] Conservation of Size Points, AKA: Partial Credit for Backlogs

                  Steve Teske wrote:
                  > We are having a lively debate about Size Points...
                  >
                  > ...giving partial
                  > credit to the failing sprint
                  >
                  > ...give yourself zero credit
                  > in the failing sprint and carry over...
                  > ...full credit from the original size points (don't reduce).
                  >
                  > Mathematically these two paradigms result in EXACTLY the same
                  > velocity calculation.
                  >
                  > Here's my dilema: I think the math above does not reflect true
                  > velocity. I don't have a palatable explanation of why partial credit
                  > schemes will fail to delivery the correct velocity measurement. But
                  > the harder isssue is the politics of counting instantaneous velocity
                  > (counting only the things that are DONE) and discarding the size
                  > points of partially completed work appears to reduce the overall
                  > backlog size. It appears that size points are disappearing if I
                  > count only the "Done" work. While I believe this promotes a better
                  > understanding of TRUE velocity, the politics and the Math of what I
                  > call non-conservation of size points is apparently either my
                  > misunderstanding of SCRUM or it's a bridge too far for my director to
                  > sell to Project Management because in non-conservation of size
                  > points, it looks like size points are mysteriously disappearing.

                  Steve, I was traveling yesterday and see you've already received a lot
                  of good replies. I'd like to approach this in a slightly different
                  fashion, though others have hinted in this direction.

                  Why does your organization give so much importance to story points? Why
                  do you think they're a credit to the team? Why does your Project
                  Management think they're something to put in the bank?

                  What is your goal? To produce valuable, working software? Or to
                  collect story points?

                  Why do you use story points? To measure the worth of the team? Or to
                  help the team select approximately the right amount of work for the next
                  iteration?

                  - George

                  --
                  ------------ --------- --------- --------- --------- --------- -
                  * George Dinwiddie * http://blog. gdinwiddie. com
                  Software Development http://www.idiacomp uting.com
                  Consultant and Coach http://www.agilemar yland.org
                  ------------ --------- --------- --------- --------- --------- -




                  Find car news, reviews and more Looking to change your car this year?
                • woynam
                  That s better. :-) Yes, I agree. We spend too much time worrying about estimation and the math surrounding stories. All this effort doesn t do a thing to
                  Message 8 of 17 , Apr 2, 2009
                    That's better. :-)

                    Yes, I agree. We spend too much time worrying about estimation and the math surrounding stories. All this effort doesn't do a thing to improve the team's ability to deliver stories. Whether we get credit for 5 out of 10 points, or 9 out of 10, doesn't change the fact that one 5 point story is ready for production.

                    My point was that averaging velocity across (n) Sprints smooths out the rough spots, and gives a fairly accurate measure of the team's velocity without micro-managing the numbers.

                    I've posted our burn-up chart in the files section from our most recent large project (30+ iterations). The chart has a bar for velocity (3 month average), and you can see it doesn't vary all that much. The team got done what the team got done. Our velocity improved only when we address engineering practices and removed impediments. Our velocity didn't change because we got better at managing the numbers.

                    Mark

                    --- In scrumdevelopment@yahoogroups.com, mike.dwyer1@... wrote:
                    >
                    > I took this to be a 4/1 post. Sorry
                    >
                    > But since you are serious on this, let's ask some simple questions.
                    > Is this preoccupation with the math of story points clouding the actual value they bring? Keep in mind that velocity is nothing more than a regression to the mean and since we choose not to keep teams together long enough for it to have any statistical relevance. If your projects are over in 6 - 12 months 8 - 24 samples are useless in a linear regression. Now if we want to think in trends that is another story and another slope to slide on.
                    > But trends are estimates and that is it they don't go any where else
                    >
                    > So what can a story sizing do? Hmm create a collaborative and self correcting map of the capability to deliver value. If you suck at doing that then you need to find this out and do something about.
                    > Focusing on giving yourself credit doesn't make that happen. Try spending time on why you can't estimate
                    > Sent via BlackBerry by AT&T
                    >
                    > -----Original Message-----
                    > From: "woynam" <woyna@...>
                    >
                    > Date: Wed, 01 Apr 2009 20:03:47
                    > To: <scrumdevelopment@yahoogroups.com>
                    > Subject: [scrumdevelopment] Re: Conservation of Size Points, AKA: PartialCredit for Backlogs
                    >
                    >
                    >
                    > Mike, what on earth are you talking about? I have no idea if you agree or disagree with our comments.
                    >
                    > Mark
                    >
                    > --- In scrumdevelopment@yahoogroups.com, mike.dwyer1@ wrote:
                    > >
                    > > Then why do all this work and then cop out at the end. Stay with conventional practices folks. We need people with this kind of thinking to not consider themselves part of this community.
                    > > Agile and Scrum are about done. AIG and other loser approaches about rewarding whining and in doing so ripping off this country and this world.
                    > > Yes it hard work and not much fun. Most of all you have to lose to be successful. That is a lot better than what you are suggesting.
                    > >
                    > >
                    > > Sent via BlackBerry by AT&T
                    > >
                    > > -----Original Message-----
                    > > From: Jayanthan Bhattathiripad <jynthn@>
                    > >
                    > > Date: Wed, 01 Apr 2009 12:36:00
                    > > To: <scrumdevelopment@yahoogroups.com>
                    > > Subject: Re: [scrumdevelopment] Re: Conservation of Size Points, AKA: Partial
                    > > Credit for Backlogs
                    > >
                    > >
                    > > I agree with you, Mark. I am not sure if the overhead of splitting
                    > > stories and then calculating the balance is worth the effort. Its easier
                    > > to communicate the progress for even those stories not done using words
                    > > than numbers.
                    > >
                    > > Jayanthan
                    > >
                    > > woynam wrote:
                    > > >
                    > > >
                    > > > We elected 'b', and it worked fine. Sure, you don't get a "true"
                    > > > velocity, but velocity itself is a means to an end, not the goal of
                    > > > using story points.
                    > > >
                    > > > I found it better to use a rolling average (3 iterations) when
                    > > > calculating velocity. In general, there was always stories that
                    > > > weren't quite finished, and were credited in the next iteration. Also,
                    > > > using a rolling average helps smooth out the hills and valleys, and
                    > > > IMHO, gives a more accurate measure of the speed of the team.
                    > > >
                    > > > Mark
                    > > >
                    > > > --- In scrumdevelopment@yahoogroups.com
                    > > > <mailto:scrumdevelopment%40yahoogroups.com>, "steveteske"
                    > > > <steveteske@> wrote:
                    > > > >
                    > > > > We are having a lively debate about Size Points. I am calling the
                    > > > "Conservation of Size Points Debate", because the following practices
                    > > > of your SCRUM Masters:
                    > > > >
                    > > > > Either a) If you don't finish a backlog item, estimate the remaining
                    > > > size of the backlog and assign it to the next sprint, giving partial
                    > > > credit to the failing sprint (thus preserving the overall size points)
                    > > > >
                    > > > > or b) If you don't finish a backlog item, give yourself zero credit
                    > > > in the failing sprint and carry over the size points (without
                    > > > reduction) to the next sprint. When you actual finish the backlog, you
                    > > > get count credit for in the sprint in which it is finished...but it's
                    > > > full credit from the original size points (don't reduce).
                    > > > >
                    > > > > Mathematically these two paradigms result in EXACTLY the same
                    > > > velocity calculation.
                    > > > >
                    > > > > Here's my dilema: I think the math above does not reflect true
                    > > > velocity. I don't have a palatable explanation of why partial credit
                    > > > schemes will fail to delivery the correct velocity measurement. But
                    > > > the harder isssue is the politics of counting instantaneous velocity
                    > > > (counting only the things that are DONE) and discarding the size
                    > > > points of partially completed work appears to reduce the overall
                    > > > backlog size. It appears that size points are disappearing if I count
                    > > > only the "Done" work. While I believe this promotes a better
                    > > > understanding of TRUE velocity, the politics and the Math of what I
                    > > > call non-conservation of size points is apparently either my
                    > > > misunderstanding of SCRUM or it's a bridge too far for my director to
                    > > > sell to Project Management because in non-conservation of size points,
                    > > > it looks like size points are mysteriously disappearing.
                    > > > >
                    > > > > I don't have a problem with disappearing size points because
                    > > > according to my math, if I have TRUE velocity and the total size
                    > > > points to the next release, I've got what I need.
                    > > > >
                    > > > > I am not sure how to deal with conservation vs. non-conservation of
                    > > > size points.
                    > > > >
                    > > > > Help would be appreciated.
                    > > > >
                    > > > > Steve Teske
                    > > > > Thales Communications Inc., Clarksburg, MD
                    > > > >
                    > > >
                    > > >
                    > >
                    >
                  • mike.dwyer1@comcast.net
                    George A favor to ask. Can you lead with your response? I am living on a BB these days and my thumb is sore from scrolling to the bottom. Sent via BlackBerry
                    Message 9 of 17 , Apr 2, 2009
                      George
                      A favor to ask. Can you lead with your response? I am living on a BB these days and my thumb is sore from scrolling to the bottom.

                      Sent via BlackBerry by AT&T


                      From: George Dinwiddie
                      Date: Thu, 02 Apr 2009 08:00:55 -0400
                      To: <scrumdevelopment@yahoogroups.com>
                      Subject: Re: [scrumdevelopment] Conservation of Size Points, AKA: Partial Credit for Backlogs

                      Steve Teske wrote:

                      > We are having a lively debate about Size Points...
                      >
                      > ...giving partial
                      > credit to the failing sprint
                      >
                      > ...give yourself zero credit
                      > in the failing sprint and carry over...
                      > ...full credit from the original size points (don't reduce).
                      >
                      > Mathematically these two paradigms result in EXACTLY the same
                      > velocity calculation.
                      >
                      > Here's my dilema: I think the math above does not reflect true
                      > velocity. I don't have a palatable explanation of why partial credit
                      > schemes will fail to delivery the correct velocity measurement. But
                      > the harder isssue is the politics of counting instantaneous velocity
                      > (counting only the things that are DONE) and discarding the size
                      > points of partially completed work appears to reduce the overall
                      > backlog size. It appears that size points are disappearing if I
                      > count only the "Done" work. While I believe this promotes a better
                      > understanding of TRUE velocity, the politics and the Math of what I
                      > call non-conservation of size points is apparently either my
                      > misunderstanding of SCRUM or it's a bridge too far for my director to
                      > sell to Project Management because in non-conservation of size
                      > points, it looks like size points are mysteriously disappearing.

                      Steve, I was traveling yesterday and see you've already received a lot
                      of good replies. I'd like to approach this in a slightly different
                      fashion, though others have hinted in this direction.

                      Why does your organization give so much importance to story points? Why
                      do you think they're a credit to the team? Why does your Project
                      Management think they're something to put in the bank?

                      What is your goal? To produce valuable, working software? Or to
                      collect story points?

                      Why do you use story points? To measure the worth of the team? Or to
                      help the team select approximately the right amount of work for the next
                      iteration?

                      - George

                      --
                      ------------ --------- --------- --------- --------- --------- -
                      * George Dinwiddie * http://blog. gdinwiddie. com
                      Software Development http://www.idiacomp uting.com
                      Consultant and Coach http://www.agilemar yland.org
                      ------------ --------- --------- --------- --------- --------- -

                    • Adam Sroka
                      http://m.google.com/mail
                      Message 10 of 17 , Apr 2, 2009
                        http://m.google.com/mail

                        On Thu, Apr 2, 2009 at 7:31 AM, <mike.dwyer1@...> wrote:
                        > George
                        > A favor to ask. Can you lead with your response? I am living on a BB these
                        > days and my thumb is sore from scrolling to the bottom.
                        >
                        > Sent via BlackBerry by AT&T
                        >
                        > ________________________________
                        > From: George Dinwiddie
                        > Date: Thu, 02 Apr 2009 08:00:55 -0400
                        > To: <scrumdevelopment@yahoogroups.com>
                        > Subject: Re: [scrumdevelopment] Conservation of Size Points, AKA: Partial
                        > Credit for Backlogs
                        >
                        > Steve Teske wrote:
                        >> We are having a lively debate about Size Points...
                        >>
                        >> ...giving partial
                        >> credit to the failing sprint
                        >>
                        >> ...give yourself zero credit
                        >> in the failing sprint and carry over...
                        >> ...full credit from the original size points (don't reduce).
                        >>
                        >> Mathematically these two paradigms result in EXACTLY the same
                        >> velocity calculation.
                        >>
                        >> Here's my dilema: I think the math above does not reflect true
                        >> velocity. I don't have a palatable explanation of why partial credit
                        >> schemes will fail to delivery the correct velocity measurement. But
                        >> the harder isssue is the politics of counting instantaneous velocity
                        >> (counting only the things that are DONE) and discarding the size
                        >> points of partially completed work appears to reduce the overall
                        >> backlog size. It appears that size points are disappearing if I
                        >> count only the "Done" work. While I believe this promotes a better
                        >> understanding of TRUE velocity, the politics and the Math of what I
                        >> call non-conservation of size points is apparently either my
                        >> misunderstanding of SCRUM or it's a bridge too far for my director to
                        >> sell to Project Management because in non-conservation of size
                        >> points, it looks like size points are mysteriously disappearing.
                        >
                        > Steve, I was traveling yesterday and see you've already received a lot
                        > of good replies. I'd like to approach this in a slightly different
                        > fashion, though others have hinted in this direction.
                        >
                        > Why does your organization give so much importance to story points? Why
                        > do you think they're a credit to the team? Why does your Project
                        > Management think they're something to put in the bank?
                        >
                        > What is your goal? To produce valuable, working software? Or to
                        > collect story points?
                        >
                        > Why do you use story points? To measure the worth of the team? Or to
                        > help the team select approximately the right amount of work for the next
                        > iteration?
                        >
                        > - George
                        >
                        > --
                        > ----------------------------------------------------------
                        > * George Dinwiddie * http://blog.gdinwiddie.com
                        > Software Development http://www.idiacomputing.com
                        > Consultant and Coach http://www.agilemaryland.org
                        > ----------------------------------------------------------
                        >
                        >
                      • George Dinwiddie
                        ... Sorry, Mike, but whether I top-post or bottom-post, I ll make someone unhappy. So I tend to stick with my own preference, which is to make the post
                        Message 11 of 17 , Apr 2, 2009
                          mike.dwyer1@... wrote:
                          > George
                          > A favor to ask. Can you lead with your response? I am living on a BB
                          > these days and my thumb is sore from scrolling to the bottom.

                          Sorry, Mike, but whether I top-post or bottom-post, I'll make someone
                          unhappy. So I tend to stick with my own preference, which is to make
                          the post readable from top to bottom.

                          You might notice that I excerpted the post to which I was replying.
                          There's information content in that fact, also. I was trying to
                          highlight the specific things to which I was responding.

                          Perhaps a blackberry is not the best tool for participating in a mailing
                          list.

                          - George

                          --
                          ----------------------------------------------------------------------
                          * George Dinwiddie * http://blog.gdinwiddie.com
                          Software Development http://www.idiacomputing.com
                          Consultant and Coach http://www.agilemaryland.org
                          ----------------------------------------------------------------------
                        • awible
                          Choose b. The analogy I use in this discussion of hangover is that of earnings per share. A public company that is 90% complete in closing a deal at the end of
                          Message 12 of 17 , Apr 2, 2009
                            Choose b.

                            The analogy I use in this discussion of hangover is that of earnings per share.

                            A public company that is 90% complete in closing a deal at the end of Q1, cannot claim any portion of the revenue from that deal. If they finally complete the deal in Q2, they claim the revenue then. Do they adjust their expectations up for Q2 given this understanding? No. Why? Because - at the end of Q2, they're likely to have incomplete deals as well, which will offset the positive impact of the hangover.

                            And so it goes. It all evens out. Just like iteration points.

                            And by all means, have more stories on deck to slide into the iteration if the team hits on all cylinders in the next iteration.

                            There's another smell here though... if you consistently have hangover, then something is amiss. Perhaps your stories are too big or poorly conceived (a common problem), or your planned velocity (commitment) is too high.

                            I'm currently working on a team on which hangover is rare; when it occurs, it is usually due to some exigent factor (e.g. dependency/commitment not being met by another team). If not, it usually gets done in day one of the next iteration.

                            That said, I've seen teams with massive hangover.

                            If you can't figure out the issue, I recommend bringing in an outside expert to help facilitate/diagnose. In particular, find someone who has actually participated in many teams in many environments and who has seen many problems. That is - don't find a theoretical agilist with PowerPoint at the ready... use a practiced one with post-its, markers, flipcharts, stories, analogies and enthusiasm.

                            - Adrian Wible
                            Software Development Catalyst

                            --- In scrumdevelopment@yahoogroups.com, "steveteske" <steveteske@...> wrote:
                            >
                            > We are having a lively debate about Size Points. I am calling the "Conservation of Size Points Debate", because the following practices of your SCRUM Masters:
                            >
                            > Either a) If you don't finish a backlog item, estimate the remaining size of the backlog and assign it to the next sprint, giving partial credit to the failing sprint (thus preserving the overall size points)
                            >
                            > or b) If you don't finish a backlog item, give yourself zero credit in the failing sprint and carry over the size points (without reduction) to the next sprint. When you actual finish the backlog, you get count credit for in the sprint in which it is finished...but it's full credit from the original size points (don't reduce).
                            >
                            > Mathematically these two paradigms result in EXACTLY the same velocity calculation.
                            >
                            > Here's my dilema: I think the math above does not reflect true velocity. I don't have a palatable explanation of why partial credit schemes will fail to delivery the correct velocity measurement. But the harder isssue is the politics of counting instantaneous velocity (counting only the things that are DONE) and discarding the size points of partially completed work appears to reduce the overall backlog size. It appears that size points are disappearing if I count only the "Done" work. While I believe this promotes a better understanding of TRUE velocity, the politics and the Math of what I call non-conservation of size points is apparently either my misunderstanding of SCRUM or it's a bridge too far for my director to sell to Project Management because in non-conservation of size points, it looks like size points are mysteriously disappearing.
                            >
                            > I don't have a problem with disappearing size points because according to my math, if I have TRUE velocity and the total size points to the next release, I've got what I need.
                            >
                            > I am not sure how to deal with conservation vs. non-conservation of size points.
                            >
                            > Help would be appreciated.
                            >
                            > Steve Teske
                            > Thales Communications Inc., Clarksburg, MD
                            >
                          • Adam Sroka
                            ... I consistently have hangover, but I drink a lot... ;-) The goals of the planning process are: 1) to come to a shared understanding of what needs to be done
                            Message 13 of 17 , Apr 2, 2009
                              On Thu, Apr 2, 2009 at 9:27 PM, awible <apwible@...> wrote:
                              > Choose b.
                              >
                              > The analogy I use in this discussion of hangover is that of earnings per
                              > share.
                              >
                              > A public company that is 90% complete in closing a deal at the end of Q1,
                              > cannot claim any portion of the revenue from that deal. If they finally
                              > complete the deal in Q2, they claim the revenue then. Do they adjust their
                              > expectations up for Q2 given this understanding? No. Why? Because - at the
                              > end of Q2, they're likely to have incomplete deals as well, which will
                              > offset the positive impact of the hangover.
                              >
                              > And so it goes. It all evens out. Just like iteration points.
                              >
                              > And by all means, have more stories on deck to slide into the iteration if
                              > the team hits on all cylinders in the next iteration.
                              >
                              > There's another smell here though... if you consistently have hangover, then
                              > something is amiss. Perhaps your stories are too big or poorly conceived (a
                              > common problem), or your planned velocity (commitment) is too high.
                              >

                              I consistently have hangover, but I drink a lot... ;-)

                              The goals of the planning process are: 1) to come to a shared
                              understanding of what needs to be done and what will be done in the
                              current iteration. 2) to give the business a way to understand how
                              much can be done in a given period and/or approximately when a certain
                              set of features will be complete. These goals are not well served by a
                              process that allows work to bleed across sprint boundaries.

                              The point behind allowing partial stories to "disappear" rather than
                              "hangover" is that apparent velocity decreases leading to more
                              conservative commitments that are more likely to be met. Thus the
                              process should adjust to the actual capabilities of the team.

                              > I'm currently working on a team on which hangover is rare; when it occurs,
                              > it is usually due to some exigent factor (e.g. dependency/commitment not
                              > being met by another team). If not, it usually gets done in day one of the
                              > next iteration.
                              >

                              And, therefore you don't have a problem. It is also unlikely that you
                              would have asked the question. The advice that I am giving is designed
                              to help people who frequently (Or at least occasionally) face this
                              problem. Slowing down is likely to help in the short term.

                              > That said, I've seen teams with massive hangover.
                              >

                              Probably because of a) poor estimation, b) over commitment, and/or c)
                              lack of communication (i.e. poorly understood requirements.) Lowering
                              the velocity is likely to help with both a and b. If c isn't detected
                              and dealt with the process will break down and the team will grind to
                              a halt, but estimation isn't the problem and no estimation strategy
                              will help.

                              > If you can't figure out the issue, I recommend bringing in an outside expert
                              > to help facilitate/diagnose. In particular, find someone who has actually
                              > participated in many teams in many environments and who has seen many
                              > problems. That is - don't find a theoretical agilist with PowerPoint at the
                              > ready... use a practiced one with post-its, markers, flipcharts, stories,
                              > analogies and enthusiasm.
                              >

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