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

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

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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.