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

Re: Conservation of Size Points, AKA: PartialCredit for Backlogs

Expand Messages
  • woynam
    Mike, what on earth are you talking about? I have no idea if you agree or disagree with our comments. Mark
    Message 1 of 17 , Apr 1, 2009
    • 0 Attachment
      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 2 of 17 , Apr 1, 2009
      • 0 Attachment
        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 3 of 17 , Apr 1, 2009
        • 0 Attachment
          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 4 of 17 , Apr 2, 2009
          • 0 Attachment
            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 5 of 17 , Apr 2, 2009
            • 0 Attachment
              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 6 of 17 , Apr 2, 2009
              • 0 Attachment
                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 7 of 17 , Apr 2, 2009
                • 0 Attachment
                  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 8 of 17 , Apr 2, 2009
                  • 0 Attachment
                    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 9 of 17 , Apr 2, 2009
                    • 0 Attachment
                      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 10 of 17 , Apr 2, 2009
                      • 0 Attachment
                        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 11 of 17 , Apr 2, 2009
                        • 0 Attachment
                          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.