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

Re: [scrumdevelopment] Velocity Question

Expand Messages
  • Charles Bradley - Scrum Coach CSP CSM PSM
    Rama, The only thing I can add to most of the responses already given is that you can tell your mgmt that your velocity reflects the truth.  The team s
    Message 1 of 29 , May 8, 2012
    View Source
    • 0 Attachment
      Rama,

      The only thing I can add to most of the responses already given is that you can tell your mgmt that your velocity reflects the truth.  The team's ability to complete items will ebb and flow, generally being influenced by such factors as:
      • individual impediments
      • team impediments
      • organizational impediments
      • availability of team members (vacations, matrixed/shared team members, training, etc)
      • unknown risks/complexity of items
      • development practices
      • the team's ability and experience with User Stories, Scrum, Story Points, and Velocity
      Velocity is a (generally) self correcting planning tool to reduce the cone of uncertainty in the forecast of delivery dates.  It takes time to reduce the cone of uncertainty.

      You mention Sprint 1.  If it was truly this team's Sprint 1, then I would also explain to management that velocity can be very volatile during the first 3-10 sprints, and that incremental improvements will be made to help smooth it out significantly over time.  But again, it will never be completely consistent, because Scrum team members are not clairvoyants.

      Sounds like your management could use some Scrum training or coaching.
       
      -------
      Charles Bradley
      http://www.ScrumCrazy.com




      From: Rama Bharti <ramabharti@...>
      To: scrumdevelopment@yahoogroups.com
      Sent: Sunday, April 22, 2012 9:31 PM
      Subject: [scrumdevelopment] Velocity Question

      Hi,

      I have a question on velocity.

      For instance, you have sprint 1 and sprint 2.

      Sprint 1 has 5 stories which in total is 50 story points. Each story
      is of size 10 story point.
      Sprint 2 has 5 stories which in total is 50 story points. Each story
      is of size 10 story point.

      Now sprint 1 ends with 3 stories completed and 2 story partially
      completed( 80 %done). What will be velocity of Sprint 1? I assume it
      will be 30.

      Now pending 2 stories are moved to sprint 2. and at the end of sprint
      2 , all seven stories are finished( 2 which were moved from Sprint1
      and 5 Sprint2 stories). So velocity of sprint 2 is  70.

      How do you explain this difference in velocity to management?


      Thanks.


      ------------------------------------

      To Post a message, send it to:  scrumdevelopment@...
      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

      <*> To visit your group on the web, go to:
          http://groups.yahoo.com/group/scrumdevelopment/

      <*> Your email settings:
          Individual Email | Traditional

      <*> To change settings online go to:
          http://groups.yahoo.com/group/scrumdevelopment/join
          (Yahoo! ID required)

      <*> To change settings via email:
          scrumdevelopment-digest@yahoogroups.com
          scrumdevelopment-fullfeatured@yahoogroups.com

      <*> To unsubscribe from this group, send an email to:
          scrumdevelopment-unsubscribe@yahoogroups.com

      <*> Your use of Yahoo! Groups is subject to:
          http://docs.yahoo.com/info/terms/



    • Rama Bharti
      Thanks for your reply Charles. It clears my doubt. Regards, Rama On Tue, May 8, 2012 at 6:19 PM, Charles Bradley - Scrum Coach CSP CSM PSM I
      Message 2 of 29 , May 8, 2012
      View Source
      • 0 Attachment
        Thanks for your reply Charles. It clears my doubt.
         
        Regards,
        Rama

        On Tue, May 8, 2012 at 6:19 PM, Charles Bradley - Scrum Coach CSP CSM PSM I <chuck-lists2@...> wrote:
         

        Rama,

        The only thing I can add to most of the responses already given is that you can tell your mgmt that your velocity reflects the truth.  The team's ability to complete items will ebb and flow, generally being influenced by such factors as:
        • individual impediments
        • team impediments
        • organizational impediments
        • availability of team members (vacations, matrixed/shared team members, training, etc)
        • unknown risks/complexity of items
        • development practices
        • the team's ability and experience with User Stories, Scrum, Story Points, and Velocity
        Velocity is a (generally) self correcting planning tool to reduce the cone of uncertainty in the forecast of delivery dates.  It takes time to reduce the cone of uncertainty.

        You mention Sprint 1.  If it was truly this team's Sprint 1, then I would also explain to management that velocity can be very volatile during the first 3-10 sprints, and that incremental improvements will be made to help smooth it out significantly over time.  But again, it will never be completely consistent, because Scrum team members are not clairvoyants.

        Sounds like your management could use some Scrum training or coaching.
         
        -------
        Charles Bradley
        http://www.ScrumCrazy.com




        From: Rama Bharti <ramabharti@...>
        To: scrumdevelopment@yahoogroups.com
        Sent: Sunday, April 22, 2012 9:31 PM
        Subject: [scrumdevelopment] Velocity Question

        Hi,

        I have a question on velocity.

        For instance, you have sprint 1 and sprint 2.

        Sprint 1 has 5 stories which in total is 50 story points. Each story
        is of size 10 story point.
        Sprint 2 has 5 stories which in total is 50 story points. Each story
        is of size 10 story point.

        Now sprint 1 ends with 3 stories completed and 2 story partially
        completed( 80 %done). What will be velocity of Sprint 1? I assume it
        will be 30.

        Now pending 2 stories are moved to sprint 2. and at the end of sprint
        2 , all seven stories are finished( 2 which were moved from Sprint1
        and 5 Sprint2 stories). So velocity of sprint 2 is  70.

        How do you explain this difference in velocity to management?


        Thanks.


        ------------------------------------

        To Post a message, send it to:  scrumdevelopment@...
        To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

        <*> To visit your group on the web, go to:
            http://groups.yahoo.com/group/scrumdevelopment/

        <*> Your email settings:
            Individual Email | Traditional

        <*> To change settings online go to:
            http://groups.yahoo.com/group/scrumdevelopment/join
            (Yahoo! ID required)

        <*> To change settings via email:
            scrumdevelopment-digest@yahoogroups.com
            scrumdevelopment-fullfeatured@yahoogroups.com

        <*> To unsubscribe from this group, send an email to:
            scrumdevelopment-unsubscribe@yahoogroups.com

        <*> Your use of Yahoo! Groups is subject to:
            http://docs.yahoo.com/info/terms/




      • gopinath
        Mark, I agree with you on If you re-estimate the stories, the velocity will not reflect their original size. Preserving the information about the original
        Message 3 of 29 , May 8, 2012
        View Source
        • 0 Attachment
          Mark,

          I agree with you on "If you re-estimate the stories, the velocity will not reflect their original size."

          Preserving the information about the original size estimate is one approach. I won't say it is wrong. It may be useful while doing relative estimation.

          But I tend towards re-prioritizing and re-estimating the unfinished stories in the next Sprint as it reflects the current situation better.

          This blog post by David Starr explains very clearly why we need to do so:
          http://elegantcode.com/2008/09/16/what-to-do-with-left-over-stories/

          Gopinath





          --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:
          >
          >
          > No, that is not correct. The velocity for Sprint 1 will not include the unfinished stories. Thus, the full size of the stories will be part of the velocity calculation for Sprint 2. If you re-estimate the stories, the velocity will not reflect their original size.
          >
          > Again, this is the reason many recommend using a rolling average when calculating velocity. A 5 point story that's completed during the first day of the 2nd Sprint will contribute zero points towards the velocity of the first Sprint, and 5 points towards the velocity of the 2nd Sprint, even though there was only a small amount of work remaining.
          >
          > Mark
          >
          >
          > --- In scrumdevelopment@yahoogroups.com, "gopinath" <gopinath_ram@> wrote:
          > >
          > > I am in agreement with previous responses to this question.
          > > However at the beginning of Sprint 2 you should re-estimate the story points for the two partially finished stories carried over from Sprint 1.
          > >
          > > Gopinath
          > >
          > >
          > > --- In scrumdevelopment@yahoogroups.com, Rama Bharti <ramabharti@> wrote:
          > > >
          > > > Hi,
          > > >
          > > > I have a question on velocity.
          > > >
          > > > For instance, you have sprint 1 and sprint 2.
          > > >
          > > > Sprint 1 has 5 stories which in total is 50 story points. Each story
          > > > is of size 10 story point.
          > > > Sprint 2 has 5 stories which in total is 50 story points. Each story
          > > > is of size 10 story point.
          > > >
          > > > Now sprint 1 ends with 3 stories completed and 2 story partially
          > > > completed( 80 %done). What will be velocity of Sprint 1? I assume it
          > > > will be 30.
          > > >
          > > > Now pending 2 stories are moved to sprint 2. and at the end of sprint
          > > > 2 , all seven stories are finished( 2 which were moved from Sprint1
          > > > and 5 Sprint2 stories). So velocity of sprint 2 is 70.
          > > >
          > > > How do you explain this difference in velocity to management?
          > > >
          > > >
          > > > Thanks.
          > > >
          > >
          >
        • Charles Bradley - Scrum Coach CSP CSM PSM
          While I think David makes some good points in his blog post, I have found in my experiences that the value obtained by re-estimating and re-prioritizing of
          Message 4 of 29 , May 8, 2012
          View Source
          • 0 Attachment
            While I think David makes some good points in his blog post, I have found in my experiences that the value obtained by re-estimating and re-prioritizing of stories is minimal across (my experiences with)multiple teams and organizations.  The value is further minimized by getting a team to darn near eliminate carryover stories altogether.  I'd rather focus on coaching a team to avoid carryovers altogether (and keep stories small) than having to coach them on some rarely valuable practice to make sure we're providing the nth degree of transparency and re-focus of the product backlog due to carryover stories.

            I do leave the door open, however, that a very small percentage of teams will get a lot of value out of re-estimating and re-prioritizing the stories as David suggests.  My guess is that this would be teams that have larger stories, longer sprints (like 1 month) and have business priorities that change quite often (due to actual changing business conditions -- not business dysfunction) -- and if that was the case, I would instead encourage them to go with smaller stories and a shorter sprint duration.  :-)  Maybe there are other rare cases that I cannot think of -- any help in enlightening me here would be much appreciated.

            As such, I prefer the "leave the story estimate alone once it becomes WIP(Work In Progress)" strategy.
             
            -------
            Charles Bradley
            http://www.ScrumCrazy.com




            From: gopinath <gopinath_ram@...>
            To: scrumdevelopment@yahoogroups.com
            Sent: Tuesday, May 8, 2012 11:09 PM
            Subject: [scrumdevelopment] Re: Velocity Question



            Mark,

            I agree with you on "If you re-estimate the stories, the velocity will not reflect their original size."

            Preserving the information about the original size estimate is one approach. I won't say it is wrong. It may be useful while doing relative estimation.

            But I tend towards re-prioritizing and re-estimating the unfinished stories in the next Sprint as it reflects the current situation better.

            This blog post by David Starr explains very clearly why we need to do so:
            http://elegantcode.com/2008/09/16/what-to-do-with-left-over-stories/

            Gopinath





            --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:
            >
            >
            > No, that is not correct. The velocity for Sprint 1 will not include the unfinished stories. Thus, the full size of the stories will be part of the velocity calculation for Sprint 2. If you re-estimate the stories, the velocity will not reflect their original size.
            >
            > Again, this is the reason many recommend using a rolling average when calculating velocity. A 5 point story that's completed during the first day of the 2nd Sprint will contribute zero points towards the velocity of the first Sprint, and 5 points towards the velocity of the 2nd Sprint, even though there was only a small amount of work remaining.
            >
            > Mark
            >
            >
            > --- In scrumdevelopment@yahoogroups.com, "gopinath" <gopinath_ram@> wrote:
            > >
            > > I am in agreement with previous responses to this question.
            > > However at the beginning of  Sprint 2 you should re-estimate the story points for the two partially finished stories carried over from Sprint 1.
            > >
            > > Gopinath
            > >
            > >
            > > --- In scrumdevelopment@yahoogroups.com, Rama Bharti <ramabharti@> wrote:
            > > >
            > > > Hi,
            > > >
            > > > I have a question on velocity.
            > > >
            > > > For instance, you have sprint 1 and sprint 2.
            > > >
            > > > Sprint 1 has 5 stories which in total is 50 story points. Each story
            > > > is of size 10 story point.
            > > > Sprint 2 has 5 stories which in total is 50 story points. Each story
            > > > is of size 10 story point.
            > > >
            > > > Now sprint 1 ends with 3 stories completed and 2 story partially
            > > > completed( 80 %done). What will be velocity of Sprint 1? I assume it
            > > > will be 30.
            > > >
            > > > Now pending 2 stories are moved to sprint 2. and at the end of sprint
            > > > 2 , all seven stories are finished( 2 which were moved from Sprint1
            > > > and 5 Sprint2 stories). So velocity of sprint 2 is  70.
            > > >
            > > > How do you explain this difference in velocity to management?
            > > >
            > > >
            > > > Thanks.
            > > >
            > >
            >




            ------------------------------------

            To Post a message, send it to:  scrumdevelopment@...
            To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

            <*> To visit your group on the web, go to:
                http://groups.yahoo.com/group/scrumdevelopment/

            <*> Your email settings:
                Individual Email | Traditional

            <*> To change settings online go to:
                http://groups.yahoo.com/group/scrumdevelopment/join
                (Yahoo! ID required)

            <*> To change settings via email:
                scrumdevelopment-digest@yahoogroups.com
                scrumdevelopment-fullfeatured@yahoogroups.com

            <*> To unsubscribe from this group, send an email to:
                scrumdevelopment-unsubscribe@yahoogroups.com

            <*> Your use of Yahoo! Groups is subject to:
                http://docs.yahoo.com/info/terms/



          • woynam
            I completely agree, Lance. I ve been harping for years that we spend *way* too much time focusing on estimation (and velocity) related skills and issues (i.e
            Message 5 of 29 , May 9, 2012
            View Source
            • 0 Attachment
              I completely agree, Lance. I've been harping for years that we spend *way* too much time focusing on estimation (and velocity) related skills and issues (i.e metrics), and not enough time talking about skills that will actually get the stories finished sooner with better quality.

              A "perfect" estimate will never deliver anything sooner. A "perfect" velocity calculation will never deliver code sooner. "Correctly" labeling a bug/feature will never deliver code sooner.

              On the other hand, improved testing, integration, design, and refactoring *will* help deliver value sooner.

              Mark


              --- In scrumdevelopment@yahoogroups.com, "extremeprogrammer" <LanceWalton@...> wrote:
              >
              > The rolling average may be a good idea, because there will always be variation in velocity from sprint to sprint and it can help with longer term planning.
              >
              > However, using it to smooth the effect of stories-not-completed-in-a-single-sprint allows the team to avoid the very thing that time-boxed sprints are meant to bring out in Scrum. The time-boxed-sprint sets up a conflict that is central to Scrum's inspect and adapt activities. There are alternatives to time-boxing that avoid this conflict, of course.
              >
              > Forget about how much the estimates are, what management thinks, etc. The time-boxed sprint has told this team at least one important thing (in my view). Can the team understand what it's telling them? Can the team come up with a way to do better. They should not do this by trying to explain away the data with mathematical manipulations. They should do this by changing something that at least offers the potential of genuine improvement.
              >
              > Or they could *not* change anything. They can choose. Or not. It's totally up to them...
              >
              > Regards,
              >
              > Lance
              >
              > --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@> wrote:
              > >
              > >
              > > No, that is not correct. The velocity for Sprint 1 will not include the unfinished stories. Thus, the full size of the stories will be part of the velocity calculation for Sprint 2. If you re-estimate the stories, the velocity will not reflect their original size.
              > >
              > > Again, this is the reason many recommend using a rolling average when calculating velocity. A 5 point story that's completed during the first day of the 2nd Sprint will contribute zero points towards the velocity of the first Sprint, and 5 points towards the velocity of the 2nd Sprint, even though there was only a small amount of work remaining.
              > >
              > > Mark
              > >
              > >
              > > --- In scrumdevelopment@yahoogroups.com, "gopinath" <gopinath_ram@> wrote:
              > > >
              > > > I am in agreement with previous responses to this question.
              > > > However at the beginning of Sprint 2 you should re-estimate the story points for the two partially finished stories carried over from Sprint 1.
              > > >
              > > > Gopinath
              > > >
              > > >
              > > > --- In scrumdevelopment@yahoogroups.com, Rama Bharti <ramabharti@> wrote:
              > > > >
              > > > > Hi,
              > > > >
              > > > > I have a question on velocity.
              > > > >
              > > > > For instance, you have sprint 1 and sprint 2.
              > > > >
              > > > > Sprint 1 has 5 stories which in total is 50 story points. Each story
              > > > > is of size 10 story point.
              > > > > Sprint 2 has 5 stories which in total is 50 story points. Each story
              > > > > is of size 10 story point.
              > > > >
              > > > > Now sprint 1 ends with 3 stories completed and 2 story partially
              > > > > completed( 80 %done). What will be velocity of Sprint 1? I assume it
              > > > > will be 30.
              > > > >
              > > > > Now pending 2 stories are moved to sprint 2. and at the end of sprint
              > > > > 2 , all seven stories are finished( 2 which were moved from Sprint1
              > > > > and 5 Sprint2 stories). So velocity of sprint 2 is 70.
              > > > >
              > > > > How do you explain this difference in velocity to management?
              > > > >
              > > > >
              > > > > Thanks.
              > > > >
              > > >
              > >
              >
            • woynam
              I have no problem re-estimating stories in the backlog that haven t started. It sounds like you re trying to equate story points with duration. A story point
              Message 6 of 29 , May 9, 2012
              View Source
              • 0 Attachment
                I have no problem re-estimating stories in the backlog that haven't started.

                It sounds like you're trying to equate story points with duration. A story point represents a measure of value/size, not duration. A point point story not delivered is worth nothing to the business. If it's completed on the first day of the next Sprint, then the full value of 5 points is available at the end of the 2nd Sprint when the product is delivered.

                Velocity is intended to be a rough planning tool. Spending time re-estimating work in progress is a smell. The time should be spent discussing why the story was not delivered, rather than the amount of effort required to complete it.

                Mark


                --- In scrumdevelopment@yahoogroups.com, "gopinath" <gopinath_ram@...> wrote:
                >
                >
                >
                > Mark,
                >
                > I agree with you on "If you re-estimate the stories, the velocity will not reflect their original size."
                >
                > Preserving the information about the original size estimate is one approach. I won't say it is wrong. It may be useful while doing relative estimation.
                >
                > But I tend towards re-prioritizing and re-estimating the unfinished stories in the next Sprint as it reflects the current situation better.
                >
                > This blog post by David Starr explains very clearly why we need to do so:
                > http://elegantcode.com/2008/09/16/what-to-do-with-left-over-stories/
                >
                > Gopinath
                >
                >
                >
                >
                >
                > --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@> wrote:
                > >
                > >
                > > No, that is not correct. The velocity for Sprint 1 will not include the unfinished stories. Thus, the full size of the stories will be part of the velocity calculation for Sprint 2. If you re-estimate the stories, the velocity will not reflect their original size.
                > >
                > > Again, this is the reason many recommend using a rolling average when calculating velocity. A 5 point story that's completed during the first day of the 2nd Sprint will contribute zero points towards the velocity of the first Sprint, and 5 points towards the velocity of the 2nd Sprint, even though there was only a small amount of work remaining.
                > >
                > > Mark
                > >
                > >
                > > --- In scrumdevelopment@yahoogroups.com, "gopinath" <gopinath_ram@> wrote:
                > > >
                > > > I am in agreement with previous responses to this question.
                > > > However at the beginning of Sprint 2 you should re-estimate the story points for the two partially finished stories carried over from Sprint 1.
                > > >
                > > > Gopinath
                > > >
                > > >
                > > > --- In scrumdevelopment@yahoogroups.com, Rama Bharti <ramabharti@> wrote:
                > > > >
                > > > > Hi,
                > > > >
                > > > > I have a question on velocity.
                > > > >
                > > > > For instance, you have sprint 1 and sprint 2.
                > > > >
                > > > > Sprint 1 has 5 stories which in total is 50 story points. Each story
                > > > > is of size 10 story point.
                > > > > Sprint 2 has 5 stories which in total is 50 story points. Each story
                > > > > is of size 10 story point.
                > > > >
                > > > > Now sprint 1 ends with 3 stories completed and 2 story partially
                > > > > completed( 80 %done). What will be velocity of Sprint 1? I assume it
                > > > > will be 30.
                > > > >
                > > > > Now pending 2 stories are moved to sprint 2. and at the end of sprint
                > > > > 2 , all seven stories are finished( 2 which were moved from Sprint1
                > > > > and 5 Sprint2 stories). So velocity of sprint 2 is 70.
                > > > >
                > > > > How do you explain this difference in velocity to management?
                > > > >
                > > > >
                > > > > Thanks.
                > > > >
                > > >
                > >
                >
              • Bret Wortman
                This is one of those great, ought to be obvious statements that just leapt off the screen at me today. Awesome. I need to frame this sentence, Mark.
                Message 7 of 29 , May 9, 2012
                View Source
                • 0 Attachment
                  This is one of those great, ought to be obvious statements that just leapt off the screen at me today. Awesome. I need to frame this sentence, Mark.
                   

                  The time should be spent discussing why the story was not delivered, rather than the amount of effort required to complete it.

                  --- In scrumdevelopment@yahoogroups.com, "gopinath" <gopinath_ram@...> wrote:
                  >
                  >
                  >
                  > Mark,
                  >
                  > I agree with you on "If you re-estimate the stories, the velocity will not reflect their original size."
                  >
                  > Preserving the information about the original size estimate is one approach. I won't say it is wrong. It may be useful while doing relative estimation.
                  >
                  > But I tend towards re-prioritizing and re-estimating the unfinished stories in the next Sprint as it reflects the current situation better.
                  >
                  > This blog post by David Starr explains very clearly why we need to do so:
                  > http://elegantcode.com/2008/09/16/what-to-do-with-left-over-stories/
                  >
                  > Gopinath
                  >
                  >
                  >
                  >
                  >
                  > --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@> wrote:
                  > >
                  > >
                  > > No, that is not correct. The velocity for Sprint 1 will not include the unfinished stories. Thus, the full size of the stories will be part of the velocity calculation for Sprint 2. If you re-estimate the stories, the velocity will not reflect their original size.
                  > >
                  > > Again, this is the reason many recommend using a rolling average when calculating velocity. A 5 point story that's completed during the first day of the 2nd Sprint will contribute zero points towards the velocity of the first Sprint, and 5 points towards the velocity of the 2nd Sprint, even though there was only a small amount of work remaining.
                  > >
                  > > Mark
                  > >
                  > >
                  > > --- In scrumdevelopment@yahoogroups.com, "gopinath" <gopinath_ram@> wrote:
                  > > >
                  > > > I am in agreement with previous responses to this question.
                  > > > However at the beginning of Sprint 2 you should re-estimate the story points for the two partially finished stories carried over from Sprint 1.
                  > > >
                  > > > Gopinath
                  > > >
                  > > >
                  > > > --- In scrumdevelopment@yahoogroups.com, Rama Bharti <ramabharti@> wrote:
                  > > > >
                  > > > > Hi,
                  > > > >
                  > > > > I have a question on velocity.
                  > > > >
                  > > > > For instance, you have sprint 1 and sprint 2.
                  > > > >
                  > > > > Sprint 1 has 5 stories which in total is 50 story points. Each story
                  > > > > is of size 10 story point.
                  > > > > Sprint 2 has 5 stories which in total is 50 story points. Each story
                  > > > > is of size 10 story point.
                  > > > >
                  > > > > Now sprint 1 ends with 3 stories completed and 2 story partially
                  > > > > completed( 80 %done). What will be velocity of Sprint 1? I assume it
                  > > > > will be 30.
                  > > > >
                  > > > > Now pending 2 stories are moved to sprint 2. and at the end of sprint
                  > > > > 2 , all seven stories are finished( 2 which were moved from Sprint1
                  > > > > and 5 Sprint2 stories). So velocity of sprint 2 is 70.
                  > > > >
                  > > > > How do you explain this difference in velocity to management?
                  > > > >
                  > > > >
                  > > > > Thanks.
                  > > > >
                  > > >
                  > >
                  >


                • gopinath
                  Mark, I am not trying to equate story points with duration. Not sure what made it sound otherwise. Sorry if I was not clear enough. All I am trying to say is -
                  Message 8 of 29 , May 9, 2012
                  View Source
                  • 0 Attachment
                    Mark,

                    I am not trying to equate story points with duration. Not sure what made it sound otherwise. Sorry if I was not clear enough.

                    All I am trying to say is - no credit to be given for a partially completed story in Sprint 1. And the work (i.e. in terms of size) which remains in that story has to be treated as a new backlog item, re-prioritized (if necessary) and re-estimated at the beginning of Sprint 2. This will give a closer indication to the size/complexity of the work to be undertaken in Sprint 2.

                    Not sure whether you went through the link which I had given as reference
                    http://elegantcode.com/2008/09/16/what-to-do-with-left-over-stories/
                    This fully describes what I intended to convey.

                    And yes as you rightly say,time should be spent discussing why the story was not delivered and how to ensure that such occurrences are minimized. This has to be done in during Sprint 1 retrospective.

                    Gopinath







                    --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:
                    >
                    >
                    > I have no problem re-estimating stories in the backlog that haven't started.
                    >
                    > It sounds like you're trying to equate story points with duration. A story point represents a measure of value/size, not duration. A point point story not delivered is worth nothing to the business. If it's completed on the first day of the next Sprint, then the full value of 5 points is available at the end of the 2nd Sprint when the product is delivered.
                    >
                    > Velocity is intended to be a rough planning tool. Spending time re-estimating work in progress is a smell. The time should be spent discussing why the story was not delivered, rather than the amount of effort required to complete it.
                    >
                    > Mark
                    >
                    >
                    > --- In scrumdevelopment@yahoogroups.com, "gopinath" <gopinath_ram@> wrote:
                    > >
                    > >
                    > >
                    > > Mark,
                    > >
                    > > I agree with you on "If you re-estimate the stories, the velocity will not reflect their original size."
                    > >
                    > > Preserving the information about the original size estimate is one approach. I won't say it is wrong. It may be useful while doing relative estimation.
                    > >
                    > > But I tend towards re-prioritizing and re-estimating the unfinished stories in the next Sprint as it reflects the current situation better.
                    > >
                    > > This blog post by David Starr explains very clearly why we need to do so:
                    > > http://elegantcode.com/2008/09/16/what-to-do-with-left-over-stories/
                    > >
                    > > Gopinath
                    > >
                    > >
                    > >
                    > >
                    > >
                    > > --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@> wrote:
                    > > >
                    > > >
                    > > > No, that is not correct. The velocity for Sprint 1 will not include the unfinished stories. Thus, the full size of the stories will be part of the velocity calculation for Sprint 2. If you re-estimate the stories, the velocity will not reflect their original size.
                    > > >
                    > > > Again, this is the reason many recommend using a rolling average when calculating velocity. A 5 point story that's completed during the first day of the 2nd Sprint will contribute zero points towards the velocity of the first Sprint, and 5 points towards the velocity of the 2nd Sprint, even though there was only a small amount of work remaining.
                    > > >
                    > > > Mark
                    > > >
                    > > >
                    > > > --- In scrumdevelopment@yahoogroups.com, "gopinath" <gopinath_ram@> wrote:
                    > > > >
                    > > > > I am in agreement with previous responses to this question.
                    > > > > However at the beginning of Sprint 2 you should re-estimate the story points for the two partially finished stories carried over from Sprint 1.
                    > > > >
                    > > > > Gopinath
                    > > > >
                    > > > >
                    > > > > --- In scrumdevelopment@yahoogroups.com, Rama Bharti <ramabharti@> wrote:
                    > > > > >
                    > > > > > Hi,
                    > > > > >
                    > > > > > I have a question on velocity.
                    > > > > >
                    > > > > > For instance, you have sprint 1 and sprint 2.
                    > > > > >
                    > > > > > Sprint 1 has 5 stories which in total is 50 story points. Each story
                    > > > > > is of size 10 story point.
                    > > > > > Sprint 2 has 5 stories which in total is 50 story points. Each story
                    > > > > > is of size 10 story point.
                    > > > > >
                    > > > > > Now sprint 1 ends with 3 stories completed and 2 story partially
                    > > > > > completed( 80 %done). What will be velocity of Sprint 1? I assume it
                    > > > > > will be 30.
                    > > > > >
                    > > > > > Now pending 2 stories are moved to sprint 2. and at the end of sprint
                    > > > > > 2 , all seven stories are finished( 2 which were moved from Sprint1
                    > > > > > and 5 Sprint2 stories). So velocity of sprint 2 is 70.
                    > > > > >
                    > > > > > How do you explain this difference in velocity to management?
                    > > > > >
                    > > > > >
                    > > > > > Thanks.
                    > > > > >
                    > > > >
                    > > >
                    > >
                    >
                  • Bret Wortman
                    I read the blog post and disagree with what I read. If the team worked on the story and didn t complete it, but the story gets re-estimated and the new point
                    Message 9 of 29 , May 9, 2012
                    View Source
                    • 0 Attachment
                      I read the blog post and disagree with what I read.

                      If the team worked on the story and didn't complete it, but the story gets re-estimated and the new point value is lowered because, as the blog author points out, " The amount of work left to do to finish the story is hopefully less than the original estimate. The work remaining to finish the story is the real effort going forward. After all, some of the work is done.", then some amount of work is simply lost -- that is, the differrence between portion of work completed during the current sprint, which isn't counted toward the current sprint because the story wasn't completed, and is now lost because the story is re-estimated and the value lowered to reflect the amount of work remaining.

                      If I have a 10-point story at the start of sprint n, and the team gets it partially complete, but not Done-Done, and therefore we don't claim it in sprint n, then if we re-estimate the story and realize that there are now only 3 points of work to be completed in sprint n+1, and use that as our new estimate for sprint n+1, where did the other 7 points go? The team did those 7 points of work, but got no credit for them at all.

                      The point is that the story was a 10 point story and we don't claim credit until all work is completed. The re-estimation of the story ignores this and tries to reassess, but does so at a disservice to the team. The team's velocity shouldn't ignore the 7 points of work that were completed. Ignoring that work is worse than splitting the story, claiming some of the work in sprint n and shifting the rest to sprint n+1.

                      The team can discuss the work remaining to understand it, but shouldn't need to re-estimate the story to accomplish that....

                      I disagree with the blog's author that you can't have full credit in the sprint where the work is finally completed. I think that's precisely where you can claim full credit for the originally estimated points, though I welcome discussion on that point.


                      Bret Wortman



                      On Wed, May 9, 2012 at 11:14 AM, gopinath <gopinath_ram@...> wrote:
                       



                      Mark,

                      I am not trying to equate story points with duration. Not sure what made it sound otherwise. Sorry if I was not clear enough.

                      All I am trying to say is - no credit to be given for a partially completed story in Sprint 1. And the work (i.e. in terms of size) which remains in that story has to be treated as a new backlog item, re-prioritized (if necessary) and re-estimated at the beginning of Sprint 2. This will give a closer indication to the size/complexity of the work to be undertaken in Sprint 2.

                      Not sure whether you went through the link which I had given as reference
                      http://elegantcode.com/2008/09/16/what-to-do-with-left-over-stories/
                      This fully describes what I intended to convey.

                      And yes as you rightly say,time should be spent discussing why the story was not delivered and how to ensure that such occurrences are minimized. This has to be done in during Sprint 1 retrospective.

                      Gopinath



                      --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:
                      >
                      >
                      > I have no problem re-estimating stories in the backlog that haven't started.
                      >
                      > It sounds like you're trying to equate story points with duration. A story point represents a measure of value/size, not duration. A point point story not delivered is worth nothing to the business. If it's completed on the first day of the next Sprint, then the full value of 5 points is available at the end of the 2nd Sprint when the product is delivered.
                      >
                      > Velocity is intended to be a rough planning tool. Spending time re-estimating work in progress is a smell. The time should be spent discussing why the story was not delivered, rather than the amount of effort required to complete it.
                      >
                      > Mark
                      >
                      >
                      > --- In scrumdevelopment@yahoogroups.com, "gopinath" <gopinath_ram@> wrote:
                      > >
                      > >
                      > >
                      > > Mark,
                      > >
                      > > I agree with you on "If you re-estimate the stories, the velocity will not reflect their original size."
                      > >
                      > > Preserving the information about the original size estimate is one approach. I won't say it is wrong. It may be useful while doing relative estimation.
                      > >
                      > > But I tend towards re-prioritizing and re-estimating the unfinished stories in the next Sprint as it reflects the current situation better.
                      > >
                      > > This blog post by David Starr explains very clearly why we need to do so:
                      > > http://elegantcode.com/2008/09/16/what-to-do-with-left-over-stories/
                      > >
                      > > Gopinath
                      > >
                      > >
                      > >
                      > >
                      > >
                      > > --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@> wrote:
                      > > >
                      > > >
                      > > > No, that is not correct. The velocity for Sprint 1 will not include the unfinished stories. Thus, the full size of the stories will be part of the velocity calculation for Sprint 2. If you re-estimate the stories, the velocity will not reflect their original size.
                      > > >
                      > > > Again, this is the reason many recommend using a rolling average when calculating velocity. A 5 point story that's completed during the first day of the 2nd Sprint will contribute zero points towards the velocity of the first Sprint, and 5 points towards the velocity of the 2nd Sprint, even though there was only a small amount of work remaining.
                      > > >
                      > > > Mark
                      > > >
                      > > >
                      > > > --- In scrumdevelopment@yahoogroups.com, "gopinath" <gopinath_ram@> wrote:
                      > > > >
                      > > > > I am in agreement with previous responses to this question.
                      > > > > However at the beginning of Sprint 2 you should re-estimate the story points for the two partially finished stories carried over from Sprint 1.
                      > > > >
                      > > > > Gopinath
                      > > > >
                      > > > >
                      > > > > --- In scrumdevelopment@yahoogroups.com, Rama Bharti <ramabharti@> wrote:
                      > > > > >
                      > > > > > Hi,
                      > > > > >
                      > > > > > I have a question on velocity.
                      > > > > >
                      > > > > > For instance, you have sprint 1 and sprint 2.
                      > > > > >
                      > > > > > Sprint 1 has 5 stories which in total is 50 story points. Each story
                      > > > > > is of size 10 story point.
                      > > > > > Sprint 2 has 5 stories which in total is 50 story points. Each story
                      > > > > > is of size 10 story point.
                      > > > > >
                      > > > > > Now sprint 1 ends with 3 stories completed and 2 story partially
                      > > > > > completed( 80 %done). What will be velocity of Sprint 1? I assume it
                      > > > > > will be 30.
                      > > > > >
                      > > > > > Now pending 2 stories are moved to sprint 2. and at the end of sprint
                      > > > > > 2 , all seven stories are finished( 2 which were moved from Sprint1
                      > > > > > and 5 Sprint2 stories). So velocity of sprint 2 is 70.
                      > > > > >
                      > > > > > How do you explain this difference in velocity to management?
                      > > > > >
                      > > > > >
                      > > > > > Thanks.
                      > > > > >
                      > > > >
                      > > >
                      > >
                      >


                    • David A Barrett
                      Oh man. There s so much so wrong with this whole question. First, I m beginning to think that velocity should be considered a dirty word around here. We
                      Message 10 of 29 , May 9, 2012
                      View Source
                      • 0 Attachment
                        Oh man.  There's so much so wrong with this whole question.

                        First, I'm beginning to think that "velocity" should be considered a dirty word around here.  We see so many people asking questions and talking about it in ways that clearly indicate that it's being misused.  

                        One point at a time then:

                        1.  The goal is to look at past performance to determine the correct amount of work for the Team to commit to for the next Sprint.
                        2.  How much ESTIMATED work was done in Sprint 1?  30 SP worth of completed stories, and 16 worth of uncompleted stories.
                        3.  How much work should you put into Sprint 2?  I'd aim at about 45 SP, based on past performance, but....
                        4.  One Sprint is NO WHERE NEAR ENOUGH HISTORICAL DATA to gauge past performance.  So...
                        5.  Ask the Team what went on.  Ask them if their experience in Sprint 1 would cause them to refine any of their estimates.
                        6.  Ask the Team how much work they are willing to commit to for Sprint 2.
                        7.  Your stories are probably too big, if you even have the chance for some of them to be partially completed.  Split them up.
                        8.  What do you tell management?  Tell them to "Go away and leave the Team alone, it's only Sprint 2".

                        The Scrum rules say that the Team doesn't get "credit" (whatever the hell that is) for partially completed tasks.  Tasks are either complete or not.  But, velocity isn't really part of Scrum, it's just a tool that Scrumistas use (and is seem even more often, misuse) to help planning.  So you'll want to define it in a way that makes your planning the easiest.  So I'd count partially completed stories for purposes of calculating velocity.  But, if I can be allowed to channel Ron for a moment, if partially completed stories are making you bend your velocity rules, then stop having partially complete stories.

                        That being said, partially completed stories are something that you want to get rid of.  Re-engineer your planning process to make partially completed stories impossible.

                        Finally, the whole thing has a smell.  You missed on nearly half the stories in the first Sprint, yet you put even more work into the second Sprint???????  Even smellier, the Team somehow achieved on the bigger second Sprint??????  Bearing in mind that 2 Sprints are way too few to actually identify any patterns or trends, it still looks like there might be some kind of non-Scrum dynamic building in the way work was included in the second Sprint and completed.  Was there pressure applied?  Were the results fudged?  Was the DoD actually met?


                        Dave Barrett


                        This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please delete it and advise me (by return e-mail or otherwise) immediately.

                        Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez le supprimer et m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.
                      • Steve Ropa
                        I always struggle with the phrase has to. and its variants. I have seen teams successfully do what you are suggesting and re-estimate their stories. I have
                        Message 11 of 29 , May 9, 2012
                        View Source
                        • 0 Attachment

                          I always struggle with the phrase “has to…” and its variants.  I have seen teams successfully do what you are suggesting and re-estimate their stories.  I have seen just as many teams do what I strongly recommend and keeping the size the same.  They were every bit as successful, maybe a little bit more. 

                           

                          The reason I recommend not re-estimating the work is twofold.  Bret does a great job eloquently explaining why keeping the size the same is valuable, although I oppose the idea of “credit” at any stage of the game.  Mostly, since estimates are of minimal value in the first place, why spend valuable time re-estimating something when we could better be spending that time making software?

                           

                          From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of gopinath
                          Sent: Wednesday, May 09, 2012 9:14 AM
                          To: scrumdevelopment@yahoogroups.com
                          Subject: [scrumdevelopment] Re: Velocity Question

                           

                           



                          Mark,

                          I am not trying to equate story points with duration. Not sure what made it sound otherwise. Sorry if I was not clear enough.

                          All I am trying to say is - no credit to be given for a partially completed story in Sprint 1. And the work (i.e. in terms of size) which remains in that story has to be treated as a new backlog item, re-prioritized (if necessary) and re-estimated at the beginning of Sprint 2. This will give a closer indication to the size/complexity of the work to be undertaken in Sprint 2.

                          Not sure whether you went through the link which I had given as reference
                          http://elegantcode.com/2008/09/16/what-to-do-with-left-over-stories/
                          This fully describes what I intended to convey.

                          And yes as you rightly say,time should be spent discussing why the story was not delivered and how to ensure that such occurrences are minimized. This has to be done in during Sprint 1 retrospective.

                          Gopinath

                          --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:
                          >
                          >
                          > I have no problem re-estimating stories in the backlog that haven't started.
                          >
                          > It sounds like you're trying to equate story points with duration. A story point represents a measure of value/size, not duration. A point point story not delivered is worth nothing to the business. If it's completed on the first day of the next Sprint, then the full value of 5 points is available at the end of the 2nd Sprint when the product is delivered.
                          >
                          > Velocity is intended to be a rough planning tool. Spending time re-estimating work in progress is a smell. The time should be spent discussing why the story was not delivered, rather than the amount of effort required to complete it.
                          >
                          > Mark
                          >
                          >
                          > --- In scrumdevelopment@yahoogroups.com, "gopinath" <gopinath_ram@> wrote:
                          > >
                          > >
                          > >
                          > > Mark,
                          > >
                          > > I agree with you on "If you re-estimate the stories, the velocity will not reflect their original size."
                          > >
                          > > Preserving the information about the original size estimate is one approach. I won't say it is wrong. It may be useful while doing relative estimation.
                          > >
                          > > But I tend towards re-prioritizing and re-estimating the unfinished stories in the next Sprint as it reflects the current situation better.
                          > >
                          > > This blog post by David Starr explains very clearly why we need to do so:
                          > > http://elegantcode.com/2008/09/16/what-to-do-with-left-over-stories/
                          > >
                          > > Gopinath
                          > >
                          > >
                          > >
                          > >
                          > >
                          > > --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@> wrote:
                          > > >
                          > > >
                          > > > No, that is not correct. The velocity for Sprint 1 will not include the unfinished stories. Thus, the full size of the stories will be part of the velocity calculation for Sprint 2. If you re-estimate the stories, the velocity will not reflect their original size.
                          > > >
                          > > > Again, this is the reason many recommend using a rolling average when calculating velocity. A 5 point story that's completed during the first day of the 2nd Sprint will contribute zero points towards the velocity of the first Sprint, and 5 points towards the velocity of the 2nd Sprint, even though there was only a small amount of work remaining.
                          > > >
                          > > > Mark
                          > > >
                          > > >
                          > > > --- In scrumdevelopment@yahoogroups.com, "gopinath" <gopinath_ram@> wrote:
                          > > > >
                          > > > > I am in agreement with previous responses to this question.
                          > > > > However at the beginning of Sprint 2 you should re-estimate the story points for the two partially finished stories carried over from Sprint 1.
                          > > > >
                          > > > > Gopinath
                          > > > >
                          > > > >
                          > > > > --- In scrumdevelopment@yahoogroups.com, Rama Bharti <ramabharti@> wrote:
                          > > > > >
                          > > > > > Hi,
                          > > > > >
                          > > > > > I have a question on velocity.
                          > > > > >
                          > > > > > For instance, you have sprint 1 and sprint 2.
                          > > > > >
                          > > > > > Sprint 1 has 5 stories which in total is 50 story points. Each story
                          > > > > > is of size 10 story point.
                          > > > > > Sprint 2 has 5 stories which in total is 50 story points. Each story
                          > > > > > is of size 10 story point.
                          > > > > >
                          > > > > > Now sprint 1 ends with 3 stories completed and 2 story partially
                          > > > > > completed( 80 %done). What will be velocity of Sprint 1? I assume it
                          > > > > > will be 30.
                          > > > > >
                          > > > > > Now pending 2 stories are moved to sprint 2. and at the end of sprint
                          > > > > > 2 , all seven stories are finished( 2 which were moved from Sprint1
                          > > > > > and 5 Sprint2 stories). So velocity of sprint 2 is 70.
                          > > > > >
                          > > > > > How do you explain this difference in velocity to management?
                          > > > > >
                          > > > > >
                          > > > > > Thanks.
                          > > > > >
                          > > > >
                          > > >
                          > >
                          >

                        • woynam
                          As my mom used to say, You can t have any dessert, because you didn t finish your vegetables. I had a math teacher once who didn t give partial credit. He d
                          Message 12 of 29 , May 9, 2012
                          View Source
                          • 0 Attachment
                            As my mom used to say, "You can't have any dessert, because you didn't finish your vegetables."

                            I had a math teacher once who didn't give partial credit. He'd claim that almost getting the right answer doesn't help much when the spaceship crashes into the moon's surface.

                            When you finish your story, you can claim "credit" for delivering value to the business. If the business hands out chocolate sundaes for a completed story, I'm guessing that the team would be motivated to finish a story in the current Sprint. :-)

                            Frankly, I don't like the term "credit". Again, it smacks too much of gaming the system, with a focus on metrics, rather than delivering value.

                            Velocity is a rough planning tool. Trying to obtain precision is rather pointless. A running average is sufficient to smooth out the bumps caused by unfinished stories. The emphasis should always be on completing the stories, not getting "credit" for partial work.

                            Mark

                            --- In scrumdevelopment@yahoogroups.com, Bret Wortman <bret@...> wrote:
                            >
                            > I read the blog post and disagree with what I read.
                            >
                            > If the team worked on the story and didn't complete it, but the story gets
                            > re-estimated and the new point value is lowered because, as the blog author
                            > points out, " The amount of work left to do to finish the story is
                            > hopefully less than the original estimate. The work remaining to finish the
                            > story is the real effort going forward. After all, some of the work is
                            > done.", then some amount of work is simply lost -- that is, the differrence
                            > between portion of work completed during the current sprint, which isn't
                            > counted toward the current sprint because the story wasn't completed, and
                            > is now lost because the story is re-estimated and the value lowered to
                            > reflect the amount of work remaining.
                            >
                            > If I have a 10-point story at the start of sprint *n*, and the team gets it
                            > partially complete, but not Done-Done, and therefore we don't claim it in
                            > sprint *n, *then if we re-estimate the story and realize that there are now
                            > only 3 points of work to be completed in sprint *n+1*, and use that as our
                            > new estimate for sprint *n+1*, where did the other 7 points go? The team
                            > did those 7 points of work, but got no credit for them at all.
                            >
                            > The point is that the story was a 10 point story and we don't claim credit
                            > until all work is completed. The re-estimation of the story ignores this
                            > and tries to reassess, but does so at a disservice to the team. The team's
                            > velocity shouldn't ignore the 7 points of work that were completed.
                            > Ignoring that work is worse than splitting the story, claiming some of the
                            > work in sprint *n* and shifting the rest to sprint *n+1*.
                            >
                            > The team can discuss the work remaining to understand it, but shouldn't
                            > need to re-estimate the story to accomplish that....
                            >
                            > I disagree with the blog's author that you can't have full credit in the
                            > sprint where the work is finally completed. I think that's precisely where
                            > you can claim full credit for the originally estimated points, though I
                            > welcome discussion on that point.
                            >
                            >
                            > *Bret Wortman***
                            >
                            >
                            >
                            > On Wed, May 9, 2012 at 11:14 AM, gopinath <gopinath_ram@...> wrote:
                            >
                            > > **
                            > >
                            > >
                            > >
                            > >
                            > > Mark,
                            > >
                            > > I am not trying to equate story points with duration. Not sure what made
                            > > it sound otherwise. Sorry if I was not clear enough.
                            > >
                            > > All I am trying to say is - no credit to be given for a partially
                            > > completed story in Sprint 1. And the work (i.e. in terms of size) which
                            > > remains in that story has to be treated as a new backlog item,
                            > > re-prioritized (if necessary) and re-estimated at the beginning of Sprint
                            > > 2. This will give a closer indication to the size/complexity of the work to
                            > > be undertaken in Sprint 2.
                            > >
                            > > Not sure whether you went through the link which I had given as reference
                            > > http://elegantcode.com/2008/09/16/what-to-do-with-left-over-stories/
                            > > This fully describes what I intended to convey.
                            > >
                            > > And yes as you rightly say,time should be spent discussing why the story
                            > > was not delivered and how to ensure that such occurrences are minimized.
                            > > This has to be done in during Sprint 1 retrospective.
                            > >
                            > > Gopinath
                            > >
                            > >
                            > > --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@> wrote:
                            > > >
                            > > >
                            > > > I have no problem re-estimating stories in the backlog that haven't
                            > > started.
                            > > >
                            > > > It sounds like you're trying to equate story points with duration. A
                            > > story point represents a measure of value/size, not duration. A point point
                            > > story not delivered is worth nothing to the business. If it's completed on
                            > > the first day of the next Sprint, then the full value of 5 points is
                            > > available at the end of the 2nd Sprint when the product is delivered.
                            > > >
                            > > > Velocity is intended to be a rough planning tool. Spending time
                            > > re-estimating work in progress is a smell. The time should be spent
                            > > discussing why the story was not delivered, rather than the amount of
                            > > effort required to complete it.
                            > > >
                            > > > Mark
                            > > >
                            > > >
                            > > > --- In scrumdevelopment@yahoogroups.com, "gopinath" <gopinath_ram@>
                            > > wrote:
                            > > > >
                            > > > >
                            > > > >
                            > > > > Mark,
                            > > > >
                            > > > > I agree with you on "If you re-estimate the stories, the velocity will
                            > > not reflect their original size."
                            > > > >
                            > > > > Preserving the information about the original size estimate is one
                            > > approach. I won't say it is wrong. It may be useful while doing relative
                            > > estimation.
                            > > > >
                            > > > > But I tend towards re-prioritizing and re-estimating the unfinished
                            > > stories in the next Sprint as it reflects the current situation better.
                            > > > >
                            > > > > This blog post by David Starr explains very clearly why we need to do
                            > > so:
                            > > > > http://elegantcode.com/2008/09/16/what-to-do-with-left-over-stories/
                            > > > >
                            > > > > Gopinath
                            > > > >
                            > > > >
                            > > > >
                            > > > >
                            > > > >
                            > > > > --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@> wrote:
                            > > > > >
                            > > > > >
                            > > > > > No, that is not correct. The velocity for Sprint 1 will not include
                            > > the unfinished stories. Thus, the full size of the stories will be part of
                            > > the velocity calculation for Sprint 2. If you re-estimate the stories, the
                            > > velocity will not reflect their original size.
                            > > > > >
                            > > > > > Again, this is the reason many recommend using a rolling average
                            > > when calculating velocity. A 5 point story that's completed during the
                            > > first day of the 2nd Sprint will contribute zero points towards the
                            > > velocity of the first Sprint, and 5 points towards the velocity of the 2nd
                            > > Sprint, even though there was only a small amount of work remaining.
                            > > > > >
                            > > > > > Mark
                            > > > > >
                            > > > > >
                            > > > > > --- In scrumdevelopment@yahoogroups.com, "gopinath" <gopinath_ram@>
                            > > wrote:
                            > > > > > >
                            > > > > > > I am in agreement with previous responses to this question.
                            > > > > > > However at the beginning of Sprint 2 you should re-estimate the
                            > > story points for the two partially finished stories carried over from
                            > > Sprint 1.
                            > > > > > >
                            > > > > > > Gopinath
                            > > > > > >
                            > > > > > >
                            > > > > > > --- In scrumdevelopment@yahoogroups.com, Rama Bharti <ramabharti@>
                            > > wrote:
                            > > > > > > >
                            > > > > > > > Hi,
                            > > > > > > >
                            > > > > > > > I have a question on velocity.
                            > > > > > > >
                            > > > > > > > For instance, you have sprint 1 and sprint 2.
                            > > > > > > >
                            > > > > > > > Sprint 1 has 5 stories which in total is 50 story points. Each
                            > > story
                            > > > > > > > is of size 10 story point.
                            > > > > > > > Sprint 2 has 5 stories which in total is 50 story points. Each
                            > > story
                            > > > > > > > is of size 10 story point.
                            > > > > > > >
                            > > > > > > > Now sprint 1 ends with 3 stories completed and 2 story partially
                            > > > > > > > completed( 80 %done). What will be velocity of Sprint 1? I
                            > > assume it
                            > > > > > > > will be 30.
                            > > > > > > >
                            > > > > > > > Now pending 2 stories are moved to sprint 2. and at the end of
                            > > sprint
                            > > > > > > > 2 , all seven stories are finished( 2 which were moved from
                            > > Sprint1
                            > > > > > > > and 5 Sprint2 stories). So velocity of sprint 2 is 70.
                            > > > > > > >
                            > > > > > > > How do you explain this difference in velocity to management?
                            > > > > > > >
                            > > > > > > >
                            > > > > > > > Thanks.
                            > > > > > > >
                            > > > > > >
                            > > > > >
                            > > > >
                            > > >
                            > >
                            > >
                            > >
                            >
                          • Charles Bradley - Scrum Coach CSP CSM PSM
                            David, ... get credit (whatever the hell that is) for partially completed tasks. I wasn t aware of this.  Do you have a source for this? The one thing I can
                            Message 13 of 29 , May 9, 2012
                            View Source
                            • 0 Attachment
                              David,

                              > The Scrum rules say that the Team doesn't get "credit" (whatever the hell that is) for partially completed tasks.

                              I wasn't aware of this.  Do you have a source for this?

                              The one thing I can guess at, that you were try to say here is: "Scrum does not consider the time spent working on Sprint Backlog Items.  The work remaining and date are the only variables of interest."
                               
                              Is that what you were trying to say?

                              -------
                              Charles Bradley
                              http://www.ScrumCrazy.com




                              From: David A Barrett <dave.barrett@...>
                              To: scrumdevelopment@yahoogroups.com
                              Sent: Wednesday, May 9, 2012 9:47 AM
                              Subject: [scrumdevelopment] Re: Velocity Question



                              Oh man.  There's so much so wrong with this whole question.

                              First, I'm beginning to think that "velocity" should be considered a dirty word around here.  We see so many people asking questions and talking about it in ways that clearly indicate that it's being misused.  

                              One point at a time then:

                              1.  The goal is to look at past performance to determine the correct amount of work for the Team to commit to for the next Sprint.
                              2.  How much ESTIMATED work was done in Sprint 1?  30 SP worth of completed stories, and 16 worth of uncompleted stories.
                              3.  How much work should you put into Sprint 2?  I'd aim at about 45 SP, based on past performance, but....
                              4.  One Sprint is NO WHERE NEAR ENOUGH HISTORICAL DATA to gauge past performance.  So...
                              5.  Ask the Team what went on.  Ask them if their experience in Sprint 1 would cause them to refine any of their estimates.
                              6.  Ask the Team how much work they are willing to commit to for Sprint 2.
                              7.  Your stories are probably too big, if you even have the chance for some of them to be partially completed.  Split them up.
                              8.  What do you tell management?  Tell them to "Go away and leave the Team alone, it's only Sprint 2".

                              The Scrum rules say that the Team doesn't get "credit" (whatever the hell that is) for partially completed tasks.  Tasks are either complete or not.  But, velocity isn't really part of Scrum, it's just a tool that Scrumistas use (and is seem even more often, misuse) to help planning.  So you'll want to define it in a way that makes your planning the easiest.  So I'd count partially completed stories for purposes of calculating velocity.  But, if I can be allowed to channel Ron for a moment, if partially completed stories are making you bend your velocity rules, then stop having partially complete stories.

                              That being said, partially completed stories are something that you want to get rid of.  Re-engineer your planning process to make partially completed stories impossible.

                              Finally, the whole thing has a smell.  You missed on nearly half the stories in the first Sprint, yet you put even more work into the second Sprint???????  Even smellier, the Team somehow achieved on the bigger second Sprint??????  Bearing in mind that 2 Sprints are way too few to actually identify any patterns or trends, it still looks like there might be some kind of non-Scrum dynamic building in the way work was included in the second Sprint and completed.  Was there pressure applied?  Were the results fudged?  Was the DoD actually met?


                              Dave Barrett

                            • RonJeffries
                              Hi Bret, and all, ... I invented points, and I can tell you that this is not what I had in mind when I did it. Credit for getting things done, vs how hard
                              Message 14 of 29 , May 9, 2012
                              View Source
                              • 0 Attachment
                                Hi Bret, and all,

                                On May 9, 2012, at 11:35 AM, Bret Wortman wrote:

                                If I have a 10-point story at the start of sprint n, and the team gets it partially complete, but not Done-Done, and therefore we don't claim it in sprint n, then if we re-estimate the story and realize that there are now only 3 points of work to be completed in sprint n+1, and use that as our new estimate for sprint n+1, where did the other 7 points go? The team did those 7 points of work, but got no credit for them at all.

                                The point is that the story was a 10 point story and we don't claim credit until all work is completed. The re-estimation of the story ignores this and tries to reassess, but does so at a disservice to the team. The team's velocity shouldn't ignore the 7 points of work that were completed. Ignoring that work is worse than splitting the story, claiming some of the work in sprint n and shifting the rest to sprint n+1.

                                The team can discuss the work remaining to understand it, but shouldn't need to re-estimate the story to accomplish that....

                                I disagree with the blog's author that you can't have full credit in the sprint where the work is finally completed. I think that's precisely where you can claim full credit for the originally estimated points, though I welcome discussion on that point.

                                I invented points, and I can tell you that this is not what I had in mind when I did it.

                                "Credit" for getting things done, vs how hard they are to do, is simply not the point at all.

                                In Sprint Planning and execution, there are two things to think about that I would like to address here:

                                We need to know how much to sign up for.

                                First of all, it is useful for the TEAM to have an idea of how much work to sign up for. At the time points were invented, we were doing this by a thing we called "perfect days", where we thought "if people left us alone to do this, we could do it in n days". People found that the term "days" confused managers and product owners, who would say, five days later, "but you said it would be three days". So we converted days to points in our heads, and said the story was a three point story. Then we paid attention to how many points we did in a Sprint, and used that number to guide how much we would commit to for next time.

                                PO and management need to know how much work we'll get done over time.

                                Second, it is THOUGHT TO BE USEFUL for management and the Product Owner to have a sense of how much product they can have done by some future date. (This is nowhere near as useful as it it thought to be, as it is always always evidence of dysfunction if people are very interested in this at all. I'll come back to that.)

                                Points are only good for one of these two things.

                                Points are fairly good for deciding how much work to take on.

                                Stories actually completed per Sprint is fairly good for guessing how much product you'll have by some future date.

                                THESE ARE NOT THE SAME THING. You cannot reliably use points to decide how much product you'll have. (You can use the number of stories actually completed to guess how many stories will be completed next time: it's just necessary that they all be approximately the same size.)

                                Manage by results, not by effort

                                Points represent effort. It is very bad management to value the team in the amount of effort they put in. We do not want effort: we want results.

                                Finished stories represent results. We should value the team in terms of results, namely in terms of stories.

                                Claiming credit for points is direct evidence of dysfunction.

                                The entire exercise of deciding how many points to assign to a story remainder, so as to "claim credit" for the points, tells us that the organization is valuing effort, not results. This is very bad.

                                Story done? Count it. Story not done? Don't count it.

                                Need to decide how many stories to commit to? Keep in mind everything you know, and any code that might be useful. This is not about credit, it's about knowing how much work to take on.

                                Do not confuse planning with promising. 
                                Do not confuse inquisition with improvement.

                                There's another dysfunction lurking still. The same people who care how many points you do will likely care how many stories you do. They will show this by saying "You PROMISED me ten stories BUT you only did eight! What is wrong with you?"

                                In Scrum, the purpose of Sprint Planning is to decide how many stories to get completely done, with high quality, by the end of the Sprint. The team can use any means whatsoever to decide how much to take on. The entrails of goats have been used to good effect on some teams, and it it works for you, do it.

                                Sometimes we do not get done what we thought we could. This is not a matter for comparison of estimates and actuals, much less creative accounting for next time. This is a matter for a whole 'nother part of Scrum, the Retrospective. In the Retrospective, we sit down and say "We thought we'd get ten. We got eight. What happened? What shall we do about it?" There are many possible answers, leading to many possible improvements:

                                • We got interrupted by (the boss, meetings, ...). Let's reduce interruptions.
                                • We had to fix a critical defect. Let's bear down on testing and pair programming, so as to reduce defects.
                                • We got pulled off to work on another project. Let's cancel the Sprint next time, so management will realize they are screwing up their own project.
                                • We thought Story Six was going to be easy, but we didn't understand it. Let's be sure to get more explicit completion criteria.
                                • We thought Story Six was going to be easy, but we forgot that it required building new indexes in the database. Let's make a checklist of questions to ask about a feature and make sure database changes are on the list.

                                Nowhere on this list will we see "we thought it was a seven point story but it turned out to be an eleven", because we can't stop there. We have to say what the four points where that we forgot, and figure out what to do so we won't think we can do what we couldn't do.

                                Comparing estimates and actuals is weak Scrum at best.

                                Concern for estimate vs actual is at best an indicator that we need to Inspect and Adapt, and it is not as good an indicator even then as "We thought we could do ten stories and we did only eight", because it requires more analysis to think about it, and it leads us down a line of thinking that is not productive.

                                Counting stories is easier to do and helps avoid dysfunction.

                                Therefore, it is best to make stories close enough to the same size so that counting them is a good first cut at guessing what we can do next Sprint. (Then as we plan the Sprint, we consider them in as much more detail as needed. The estimate numbers do not help us with this, so we should not use them.)

                                Inability to work by counting stories is itself evidence of an impediment.

                                If we cannot guess how many stories we can do because the team members are specialized and all we can do is add up their individual guesses, we have just identified a major problem: we are not a very well integrated team. We need to learn to talk quickly about a story to give a quick cut at how long it will take.

                                Don't confuse planning with promising.
                                Don't confuse improved planning with improved performance.
                                Don't confuse better estimating cost with producing more value.

                                Here's my advice:

                                When stories do not get done, use the Retrospective to improve how we work rather than call for "better estimates". Continue to use history in Sprint Planning to guess how many to take on next time.

                                Do not mix the idea of points, and the idea of completed story, together. One is cost, the other is value. Value is more important.

                                Ron Jeffries
                                www.XProgramming.com
                                Sometimes I give myself admirable advice, but I am incapable of taking it.
                                -- Mary Wortley Montagu



                              • Bret Wortman
                                Thanks, Ron. You know, after I wrote that, the bit about needing to know what to sign up for this sprint was bothering me too, and what I wrote about the team
                                Message 15 of 29 , May 9, 2012
                                View Source
                                • 0 Attachment
                                  Thanks, Ron.

                                  You know, after I wrote that, the bit about needing to know what to sign up for this sprint was bothering me too, and what I wrote about "the team needs to discuss it but not re-estimate" was a last minute edit, but I should've waited and pondered more before I pressed the send button on that one.

                                  I don't view "credit" as meaning something we claim when demonstrating value to mangement. I was thinking of it in the sense of understanding how much got accomplished over time, and what I saw was some work getting lost due to the re-estimation. If we do away with velocity (and I'm getting on board with that concept, as I am with doing away with estimation altogether) then I can definitely see where asking the team what still needs to be done, and whether that work fits in with the other stories being considered is a valuable question.

                                  What I objected to was more this idea that any unfinished story needed to have some part of its work ignored, especially when it seemed that so many organizations do value velocity quite highly.


                                  Bret Wortman



                                  On Wed, May 9, 2012 at 1:58 PM, RonJeffries <ronjeffries@...> wrote:
                                   

                                  Hi Bret, and all,


                                  On May 9, 2012, at 11:35 AM, Bret Wortman wrote:

                                  If I have a 10-point story at the start of sprint n, and the team gets it partially complete, but not Done-Done, and therefore we don't claim it in sprint n, then if we re-estimate the story and realize that there are now only 3 points of work to be completed in sprint n+1, and use that as our new estimate for sprint n+1, where did the other 7 points go? The team did those 7 points of work, but got no credit for them at all.

                                  The point is that the story was a 10 point story and we don't claim credit until all work is completed. The re-estimation of the story ignores this and tries to reassess, but does so at a disservice to the team. The team's velocity shouldn't ignore the 7 points of work that were completed. Ignoring that work is worse than splitting the story, claiming some of the work in sprint n and shifting the rest to sprint n+1.

                                  The team can discuss the work remaining to understand it, but shouldn't need to re-estimate the story to accomplish that....

                                  I disagree with the blog's author that you can't have full credit in the sprint where the work is finally completed. I think that's precisely where you can claim full credit for the originally estimated points, though I welcome discussion on that point.

                                  I invented points, and I can tell you that this is not what I had in mind when I did it.

                                  "Credit" for getting things done, vs how hard they are to do, is simply not the point at all.

                                  In Sprint Planning and execution, there are two things to think about that I would like to address here:

                                  We need to know how much to sign up for.

                                  First of all, it is useful for the TEAM to have an idea of how much work to sign up for. At the time points were invented, we were doing this by a thing we called "perfect days", where we thought "if people left us alone to do this, we could do it in n days". People found that the term "days" confused managers and product owners, who would say, five days later, "but you said it would be three days". So we converted days to points in our heads, and said the story was a three point story. Then we paid attention to how many points we did in a Sprint, and used that number to guide how much we would commit to for next time.

                                  PO and management need to know how much work we'll get done over time.

                                  Second, it is THOUGHT TO BE USEFUL for management and the Product Owner to have a sense of how much product they can have done by some future date. (This is nowhere near as useful as it it thought to be, as it is always always evidence of dysfunction if people are very interested in this at all. I'll come back to that.)

                                  Points are only good for one of these two things.

                                  Points are fairly good for deciding how much work to take on.

                                  Stories actually completed per Sprint is fairly good for guessing how much product you'll have by some future date.

                                  THESE ARE NOT THE SAME THING. You cannot reliably use points to decide how much product you'll have. (You can use the number of stories actually completed to guess how many stories will be completed next time: it's just necessary that they all be approximately the same size.)

                                  Manage by results, not by effort

                                  Points represent effort. It is very bad management to value the team in the amount of effort they put in. We do not want effort: we want results.

                                  Finished stories represent results. We should value the team in terms of results, namely in terms of stories.

                                  Claiming credit for points is direct evidence of dysfunction.

                                  The entire exercise of deciding how many points to assign to a story remainder, so as to "claim credit" for the points, tells us that the organization is valuing effort, not results. This is very bad.

                                  Story done? Count it. Story not done? Don't count it.

                                  Need to decide how many stories to commit to? Keep in mind everything you know, and any code that might be useful. This is not about credit, it's about knowing how much work to take on.

                                  Do not confuse planning with promising. 
                                  Do not confuse inquisition with improvement.

                                  There's another dysfunction lurking still. The same people who care how many points you do will likely care how many stories you do. They will show this by saying "You PROMISED me ten stories BUT you only did eight! What is wrong with you?"

                                  In Scrum, the purpose of Sprint Planning is to decide how many stories to get completely done, with high quality, by the end of the Sprint. The team can use any means whatsoever to decide how much to take on. The entrails of goats have been used to good effect on some teams, and it it works for you, do it.

                                  Sometimes we do not get done what we thought we could. This is not a matter for comparison of estimates and actuals, much less creative accounting for next time. This is a matter for a whole 'nother part of Scrum, the Retrospective. In the Retrospective, we sit down and say "We thought we'd get ten. We got eight. What happened? What shall we do about it?" There are many possible answers, leading to many possible improvements:

                                  • We got interrupted by (the boss, meetings, ...). Let's reduce interruptions.
                                  • We had to fix a critical defect. Let's bear down on testing and pair programming, so as to reduce defects.
                                  • We got pulled off to work on another project. Let's cancel the Sprint next time, so management will realize they are screwing up their own project.
                                  • We thought Story Six was going to be easy, but we didn't understand it. Let's be sure to get more explicit completion criteria.
                                  • We thought Story Six was going to be easy, but we forgot that it required building new indexes in the database. Let's make a checklist of questions to ask about a feature and make sure database changes are on the list.

                                  Nowhere on this list will we see "we thought it was a seven point story but it turned out to be an eleven", because we can't stop there. We have to say what the four points where that we forgot, and figure out what to do so we won't think we can do what we couldn't do.

                                  Comparing estimates and actuals is weak Scrum at best.

                                  Concern for estimate vs actual is at best an indicator that we need to Inspect and Adapt, and it is not as good an indicator even then as "We thought we could do ten stories and we did only eight", because it requires more analysis to think about it, and it leads us down a line of thinking that is not productive.

                                  Counting stories is easier to do and helps avoid dysfunction.

                                  Therefore, it is best to make stories close enough to the same size so that counting them is a good first cut at guessing what we can do next Sprint. (Then as we plan the Sprint, we consider them in as much more detail as needed. The estimate numbers do not help us with this, so we should not use them.)

                                  Inability to work by counting stories is itself evidence of an impediment.

                                  If we cannot guess how many stories we can do because the team members are specialized and all we can do is add up their individual guesses, we have just identified a major problem: we are not a very well integrated team. We need to learn to talk quickly about a story to give a quick cut at how long it will take.

                                  Don't confuse planning with promising.
                                  Don't confuse improved planning with improved performance.
                                  Don't confuse better estimating cost with producing more value.

                                  Here's my advice:

                                  When stories do not get done, use the Retrospective to improve how we work rather than call for "better estimates". Continue to use history in Sprint Planning to guess how many to take on next time.

                                  Do not mix the idea of points, and the idea of completed story, together. One is cost, the other is value. Value is more important.

                                  Ron Jeffries
                                  www.XProgramming.com
                                  Sometimes I give myself admirable advice, but I am incapable of taking it.
                                  -- Mary Wortley Montagu




                                • Alan Dayley
                                  Just when I thought this thread was getting to long, Ron posts this excellent treatise. Thank you, Ron! Alan ... Just when I thought this thread was getting to
                                  Message 16 of 29 , May 9, 2012
                                  View Source
                                  • 0 Attachment
                                    Just when I thought this thread was getting to long, Ron posts this excellent treatise.

                                    Thank you, Ron!

                                    Alan

                                    On May 9, 2012, at 10:58 AM, RonJeffries <ronjeffries@...> wrote:

                                     

                                    Hi Bret, and all,


                                    On May 9, 2012, at 11:35 AM, Bret Wortman wrote:

                                    If I have a 10-point story at the start of sprint n, and the team gets it partially complete, but not Done-Done, and therefore we don't claim it in sprint n, then if we re-estimate the story and realize that there are now only 3 points of work to be completed in sprint n+1, and use that as our new estimate for sprint n+1, where did the other 7 points go? The team did those 7 points of work, but got no credit for them at all.

                                    The point is that the story was a 10 point story and we don't claim credit until all work is completed. The re-estimation of the story ignores this and tries to reassess, but does so at a disservice to the team. The team's velocity shouldn't ignore the 7 points of work that were completed. Ignoring that work is worse than splitting the story, claiming some of the work in sprint n and shifting the rest to sprint n+1.

                                    The team can discuss the work remaining to understand it, but shouldn't need to re-estimate the story to accomplish that....

                                    I disagree with the blog's author that you can't have full credit in the sprint where the work is finally completed. I think that's precisely where you can claim full credit for the originally estimated points, though I welcome discussion on that point.

                                    I invented points, and I can tell you that this is not what I had in mind when I did it.

                                    "Credit" for getting things done, vs how hard they are to do, is simply not the point at all.

                                    In Sprint Planning and execution, there are two things to think about that I would like to address here:

                                    We need to know how much to sign up for.

                                    First of all, it is useful for the TEAM to have an idea of how much work to sign up for. At the time points were invented, we were doing this by a thing we called "perfect days", where we thought "if people left us alone to do this, we could do it in n days". People found that the term "days" confused managers and product owners, who would say, five days later, "but you said it would be three days". So we converted days to points in our heads, and said the story was a three point story. Then we paid attention to how many points we did in a Sprint, and used that number to guide how much we would commit to for next time.

                                    PO and management need to know how much work we'll get done over time.

                                    Second, it is THOUGHT TO BE USEFUL for management and the Product Owner to have a sense of how much product they can have done by some future date. (This is nowhere near as useful as it it thought to be, as it is always always evidence of dysfunction if people are very interested in this at all. I'll come back to that.)

                                    Points are only good for one of these two things.

                                    Points are fairly good for deciding how much work to take on.

                                    Stories actually completed per Sprint is fairly good for guessing how much product you'll have by some future date.

                                    THESE ARE NOT THE SAME THING. You cannot reliably use points to decide how much product you'll have. (You can use the number of stories actually completed to guess how many stories will be completed next time: it's just necessary that they all be approximately the same size.)

                                    Manage by results, not by effort

                                    Points represent effort. It is very bad management to value the team in the amount of effort they put in. We do not want effort: we want results.

                                    Finished stories represent results. We should value the team in terms of results, namely in terms of stories.

                                    Claiming credit for points is direct evidence of dysfunction.

                                    The entire exercise of deciding how many points to assign to a story remainder, so as to "claim credit" for the points, tells us that the organization is valuing effort, not results. This is very bad.

                                    Story done? Count it. Story not done? Don't count it.

                                    Need to decide how many stories to commit to? Keep in mind everything you know, and any code that might be useful. This is not about credit, it's about knowing how much work to take on.

                                    Do not confuse planning with promising. 
                                    Do not confuse inquisition with improvement.

                                    There's another dysfunction lurking still. The same people who care how many points you do will likely care how many stories you do. They will show this by saying "You PROMISED me ten stories BUT you only did eight! What is wrong with you?"

                                    In Scrum, the purpose of Sprint Planning is to decide how many stories to get completely done, with high quality, by the end of the Sprint. The team can use any means whatsoever to decide how much to take on. The entrails of goats have been used to good effect on some teams, and it it works for you, do it.

                                    Sometimes we do not get done what we thought we could. This is not a matter for comparison of estimates and actuals, much less creative accounting for next time. This is a matter for a whole 'nother part of Scrum, the Retrospective. In the Retrospective, we sit down and say "We thought we'd get ten. We got eight. What happened? What shall we do about it?" There are many possible answers, leading to many possible improvements:

                                    • We got interrupted by (the boss, meetings, ...). Let's reduce interruptions.
                                    • We had to fix a critical defect. Let's bear down on testing and pair programming, so as to reduce defects.
                                    • We got pulled off to work on another project. Let's cancel the Sprint next time, so management will realize they are screwing up their own project.
                                    • We thought Story Six was going to be easy, but we didn't understand it. Let's be sure to get more explicit completion criteria.
                                    • We thought Story Six was going to be easy, but we forgot that it required building new indexes in the database. Let's make a checklist of questions to ask about a feature and make sure database changes are on the list.

                                    Nowhere on this list will we see "we thought it was a seven point story but it turned out to be an eleven", because we can't stop there. We have to say what the four points where that we forgot, and figure out what to do so we won't think we can do what we couldn't do.

                                    Comparing estimates and actuals is weak Scrum at best.

                                    Concern for estimate vs actual is at best an indicator that we need to Inspect and Adapt, and it is not as good an indicator even then as "We thought we could do ten stories and we did only eight", because it requires more analysis to think about it, and it leads us down a line of thinking that is not productive.

                                    Counting stories is easier to do and helps avoid dysfunction.

                                    Therefore, it is best to make stories close enough to the same size so that counting them is a good first cut at guessing what we can do next Sprint. (Then as we plan the Sprint, we consider them in as much more detail as needed. The estimate numbers do not help us with this, so we should not use them.)

                                    Inability to work by counting stories is itself evidence of an impediment.

                                    If we cannot guess how many stories we can do because the team members are specialized and all we can do is add up their individual guesses, we have just identified a major problem: we are not a very well integrated team. We need to learn to talk quickly about a story to give a quick cut at how long it will take.

                                    Don't confuse planning with promising.
                                    Don't confuse improved planning with improved performance.
                                    Don't confuse better estimating cost with producing more value.

                                    Here's my advice:

                                    When stories do not get done, use the Retrospective to improve how we work rather than call for "better estimates". Continue to use history in Sprint Planning to guess how many to take on next time.

                                    Do not mix the idea of points, and the idea of completed story, together. One is cost, the other is value. Value is more important.

                                    Ron Jeffries
                                    www.XProgramming.com
                                    Sometimes I give myself admirable advice, but I am incapable of taking it.
                                    -- Mary Wortley Montagu



                                  • Charles Bradley - Scrum Coach CSP CSM PSM
                                    +1 Ron -- Thank you for taking the time to post a thoughtful and insightful response.   ... Charles Bradley http://www.ScrumCrazy.com ... +1 Ron -- Thank you
                                    Message 17 of 29 , May 9, 2012
                                    View Source
                                    • 0 Attachment
                                      +1 Ron -- Thank you for taking the time to post a thoughtful and insightful response.
                                       
                                      -------
                                      Charles Bradley
                                      http://www.ScrumCrazy.com




                                      From: Alan Dayley <alandd@...>
                                      To: "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>
                                      Cc: "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>
                                      Sent: Wednesday, May 9, 2012 1:14 PM
                                      Subject: Re: [scrumdevelopment] Re: Velocity Question



                                      Just when I thought this thread was getting to long, Ron posts this excellent treatise.

                                      Thank you, Ron!

                                      Alan

                                      On May 9, 2012, at 10:58 AM, RonJeffries <ronjeffries@...> wrote:

                                       
                                      Hi Bret, and all,

                                      On May 9, 2012, at 11:35 AM, Bret Wortman wrote:

                                      If I have a 10-point story at the start of sprint n, and the team gets it partially complete, but not Done-Done, and therefore we don't claim it in sprint n, then if we re-estimate the story and realize that there are now only 3 points of work to be completed in sprint n+1, and use that as our new estimate for sprint n+1, where did the other 7 points go? The team did those 7 points of work, but got no credit for them at all.

                                      The point is that the story was a 10 point story and we don't claim credit until all work is completed. The re-estimation of the story ignores this and tries to reassess, but does so at a disservice to the team. The team's velocity shouldn't ignore the 7 points of work that were completed. Ignoring that work is worse than splitting the story, claiming some of the work in sprint n and shifting the rest to sprint n+1.

                                      The team can discuss the work remaining to understand it, but shouldn't need to re-estimate the story to accomplish that....

                                      I disagree with the blog's author that you can't have full credit in the sprint where the work is finally completed. I think that's precisely where you can claim full credit for the originally estimated points, though I welcome discussion on that point.

                                      I invented points, and I can tell you that this is not what I had in mind when I did it.

                                      "Credit" for getting things done, vs how hard they are to do, is simply not the point at all.

                                      In Sprint Planning and execution, there are two things to think about that I would like to address here:

                                      We need to know how much to sign up for.

                                      First of all, it is useful for the TEAM to have an idea of how much work to sign up for. At the time points were invented, we were doing this by a thing we called "perfect days", where we thought "if people left us alone to do this, we could do it in n days". People found that the term "days" confused managers and product owners, who would say, five days later, "but you said it would be three days". So we converted days to points in our heads, and said the story was a three point story. Then we paid attention to how many points we did in a Sprint, and used that number to guide how much we would commit to for next time.

                                      PO and management need to know how much work we'll get done over time.

                                      Second, it is THOUGHT TO BE USEFUL for management and the Product Owner to have a sense of how much product they can have done by some future date. (This is nowhere near as useful as it it thought to be, as it is always always evidence of dysfunction if people are very interested in this at all. I'll come back to that.)

                                      Points are only good for one of these two things.

                                      Points are fairly good for deciding how much work to take on.

                                      Stories actually completed per Sprint is fairly good for guessing how much product you'll have by some future date.

                                      THESE ARE NOT THE SAME THING. You cannot reliably use points to decide how much product you'll have. (You can use the number of stories actually completed to guess how many stories will be completed next time: it's just necessary that they all be approximately the same size.)

                                      Manage by results, not by effort

                                      Points represent effort. It is very bad management to value the team in the amount of effort they put in. We do not want effort: we want results.

                                      Finished stories represent results. We should value the team in terms of results, namely in terms of stories.

                                      Claiming credit for points is direct evidence of dysfunction.

                                      The entire exercise of deciding how many points to assign to a story remainder, so as to "claim credit" for the points, tells us that the organization is valuing effort, not results. This is very bad.

                                      Story done? Count it. Story not done? Don't count it.

                                      Need to decide how many stories to commit to? Keep in mind everything you know, and any code that might be useful. This is not about credit, it's about knowing how much work to take on.

                                      Do not confuse planning with promising. 
                                      Do not confuse inquisition with improvement.

                                      There's another dysfunction lurking still. The same people who care how many points you do will likely care how many stories you do. They will show this by saying "You PROMISED me ten stories BUT you only did eight! What is wrong with you?"

                                      In Scrum, the purpose of Sprint Planning is to decide how many stories to get completely done, with high quality, by the end of the Sprint. The team can use any means whatsoever to decide how much to take on. The entrails of goats have been used to good effect on some teams, and it it works for you, do it.

                                      Sometimes we do not get done what we thought we could. This is not a matter for comparison of estimates and actuals, much less creative accounting for next time. This is a matter for a whole 'nother part of Scrum, the Retrospective. In the Retrospective, we sit down and say "We thought we'd get ten. We got eight. What happened? What shall we do about it?" There are many possible answers, leading to many possible improvements:

                                      • We got interrupted by (the boss, meetings, ...). Let's reduce interruptions.
                                      • We had to fix a critical defect. Let's bear down on testing and pair programming, so as to reduce defects.
                                      • We got pulled off to work on another project. Let's cancel the Sprint next time, so management will realize they are screwing up their own project.
                                      • We thought Story Six was going to be easy, but we didn't understand it. Let's be sure to get more explicit completion criteria.
                                      • We thought Story Six was going to be easy, but we forgot that it required building new indexes in the database. Let's make a checklist of questions to ask about a feature and make sure database changes are on the list.

                                      Nowhere on this list will we see "we thought it was a seven point story but it turned out to be an eleven", because we can't stop there. We have to say what the four points where that we forgot, and figure out what to do so we won't think we can do what we couldn't do.

                                      Comparing estimates and actuals is weak Scrum at best.

                                      Concern for estimate vs actual is at best an indicator that we need to Inspect and Adapt, and it is not as good an indicator even then as "We thought we could do ten stories and we did only eight", because it requires more analysis to think about it, and it leads us down a line of thinking that is not productive.

                                      Counting stories is easier to do and helps avoid dysfunction.

                                      Therefore, it is best to make stories close enough to the same size so that counting them is a good first cut at guessing what we can do next Sprint. (Then as we plan the Sprint, we consider them in as much more detail as needed. The estimate numbers do not help us with this, so we should not use them.)

                                      Inability to work by counting stories is itself evidence of an impediment.

                                      If we cannot guess how many stories we can do because the team members are specialized and all we can do is add up their individual guesses, we have just identified a major problem: we are not a very well integrated team. We need to learn to talk quickly about a story to give a quick cut at how long it will take.

                                      Don't confuse planning with promising.
                                      Don't confuse improved planning with improved performance.
                                      Don't confuse better estimating cost with producing more value.

                                      Here's my advice:

                                      When stories do not get done, use the Retrospective to improve how we work rather than call for "better estimates". Continue to use history in Sprint Planning to guess how many to take on next time.

                                      Do not mix the idea of points, and the idea of completed story, together. One is cost, the other is value. Value is more important.

                                      Ron Jeffries
                                      www.XProgramming.com
                                      Sometimes I give myself admirable advice, but I am incapable of taking it.
                                      -- Mary Wortley Montagu







                                    • JackM
                                      I use a moving average for velocity. It works best. Pick moving average across 3 or 4 sprints. Cheers Jack www.agilebuddy.com
                                      Message 18 of 29 , May 9, 2012
                                      View Source
                                      • 0 Attachment
                                        I use a moving average for velocity. It works best. Pick moving average across 3 or 4 sprints.

                                        Cheers
                                        Jack
                                        www.agilebuddy.com

                                        --- In scrumdevelopment@yahoogroups.com, Rama Bharti <ramabharti@...> wrote:
                                        >
                                        > Hi,
                                        >
                                        > I have a question on velocity.
                                        >
                                        > For instance, you have sprint 1 and sprint 2.
                                        >
                                        > Sprint 1 has 5 stories which in total is 50 story points. Each story
                                        > is of size 10 story point.
                                        > Sprint 2 has 5 stories which in total is 50 story points. Each story
                                        > is of size 10 story point.
                                        >
                                        > Now sprint 1 ends with 3 stories completed and 2 story partially
                                        > completed( 80 %done). What will be velocity of Sprint 1? I assume it
                                        > will be 30.
                                        >
                                        > Now pending 2 stories are moved to sprint 2. and at the end of sprint
                                        > 2 , all seven stories are finished( 2 which were moved from Sprint1
                                        > and 5 Sprint2 stories). So velocity of sprint 2 is 70.
                                        >
                                        > How do you explain this difference in velocity to management?
                                        >
                                        >
                                        > Thanks.
                                        >
                                      Your message has been successfully submitted and would be delivered to recipients shortly.