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

Conservation of Size Points, AKA: Partial Credit for Backlogs

Expand Messages
  • steveteske
    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:
    Message 1 of 17 , Mar 31 6:39 PM
    • 0 Attachment
      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
    • Ron Jeffries
      Hello, steveteske. On Tuesday, March 31, 2009, at 9:39:19 PM, you ... What would happen if you didn t use size points at all? Serious question. Ron Jeffries
      Message 2 of 17 , Mar 31 7:32 PM
      • 0 Attachment
        Hello, steveteske. On Tuesday, March 31, 2009, at 9:39:19 PM, you
        wrote:

        > I am not sure how to deal with conservation vs. non-conservation of size points.

        What would happen if you didn't use size points at all?

        Serious question.

        Ron Jeffries
        www.XProgramming.com
        www.xprogramming.com/blog
        Attend our CSM Plus Course!
        http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
        You don't need to see my identification.
        These aren't the ideas you're looking for. Move along.
      • Pablo Emanuel
        Steve, first you stated (correctly) that, using either (a) or (b) the overall size points would be conserved, then you started worrying about the loss of
        Message 3 of 17 , Apr 1, 2009
        • 0 Attachment
          Steve,
           
          first you stated (correctly) that, using either (a) or (b) the overall size points would be conserved, then you started worrying about the "loss" of size points. I really couldn't understand where this loss come from. If you have 2 5-point stories in your backlog, and do one of them and "half-do" the other in the sprint, using (a) you would have done 7.5 points and 2.5 points would remain in the backlog, and using (b) (that IMO is the correct approach, both according to theory and in practice) you would have done 5 point and you would have 5 points in the backlog.
           
          Puzzled,
          Pablo Emanuel


           
          2009/3/31 steveteske <steveteske@...>

          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
          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
          Message 4 of 17 , Apr 1, 2009
          • 0 Attachment
            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, "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
            >
          • 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 5 of 17 , Apr 1, 2009
            • 0 Attachment
              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 6 of 17 , Apr 1, 2009
              • 0 Attachment
                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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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.