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

Why and when re-estimate

Expand Messages
  • Stephan Huez
    Hi, During the sprint planning meeting this morning, we had a discussion about whether or not to re-estimate some stories. Our team plans its sprints based on
    Message 1 of 13 , Jun 28, 2010
    • 0 Attachment
      Hi,

      During the sprint planning meeting this morning, we had a discussion about whether or not to re-estimate some stories. 

      Our team plans its sprints based on its past velocity rather than by commitment. We develop an application that implements lots of workflows. We initially estimated many stories based on the premise that they would be harder to develop and our estimates considered that stories were not ordered (there are unfortunately some dependencies). It turns out that, now that we've implemented our first workflows, all other workflows will be very much easier to implement.

      The question was: shall we re-estimate the stories that deal with workflows that we plan before the sprint when we'll develop it? I saw two points in this question. First, why re-estimate and second, when re-estimate.

      Why re-estimate?
      • We learned something new about the story
      • We merged stories or split up stories (these are new stories so one cannot call it re-estimation I'd say)
      • The relative sizes of the stories changed
      • We screwed up in our estimates
      In this very case, the remaining workflow stories will take much less time to realise and therefore, I think that their relative sizes changed and we learned something new. 

      When re-estimate?
      • If we re-estimate the stories, we shall do it prior to the sprint, during a grooming session
      What is not clear is, if we re-estimated, should we re-estimate all the stories that are along the same lines and not those for the upcoming sprint? I would say yes because that would make the remaining estimates consistent and have a more reliable burn-down or burn-up.

      If we don't re-estimate:
      • The velocity will go through the roof when we implement those stories and the variations in velocity will be greater
      • The release plan will be less realistic and the range of story points to release will vary widely
      • We keep our estimates coherent with the past but less coherent for the future. New stories will be estimated as smaller even though relative sizes will be the same
      If we re-estimate:
      • We shall re-estimate all the workflow stories to keep them coherent
      • The velocity will remain stable
      • The release plan will be positively reviewed and allow us to take more in
      • We make our estimates for the future more coherent if we add any new story
      Could you please give me your advice/insights on why and when to re-estimate? For example,
      • Do you see any other reason why you'd recommend to re-estimate?
      • Do you think that we should re-estimate those stories? I would say yes
      • Do you think that we should re-estimate all affected stories or just those for the next sprint? I would say, re-estimate all the affected ones.

      Thanks in advance,

      Stephan
    • Sarath Kummamuru
      Hi Stephan, I agree with lot of the issues that you mention with re estimation. For me re estimation creates a moving target and a whole over head of
      Message 2 of 13 , Jun 28, 2010
      • 0 Attachment
        Hi Stephan,

              I agree with lot of the issues that you mention with re estimation. For me re estimation creates a moving target and a whole over head of reestimating stuff for consistency across the whole product back log.

             Why not look at a modified velocity based on your experience and it sort of has the same effect. If you see a lot of underestimates in your story points, your guesstimate of the velocity would be higher. But now that you realize that there is much more work than you initially estimated, try to see if a reduced velocity has the same effect of indicating that you previously under estimated the work and now can go slower than initially thought.

            If you had a lot of over estimates, you would see a converse effect on velocity and it should allow for the same correction.


             the goal of story points and the way we track release progress in the release burndown is to answer :

        1. How long is it going to take to finish all the stories in a release
        2. How many of the user stories can you finish by the end of a fixed time frame.
        Dont try to add too much more complexity to the use of story points. The most important piece is for the distance you assued the release would take now your velocity is lesser than initially expected or better than initially expected.

              So without having to go through the trouble of re-estimation of all story points in your release back log, just start a sprint, experience the velocity and see how things go ?



        thanks,
        Sarath.

        On Mon, Jun 28, 2010 at 5:08 PM, Stephan Huez <stephan.huez@...> wrote:
         

        Hi,


        During the sprint planning meeting this morning, we had a discussion about whether or not to re-estimate some stories. 

        Our team plans its sprints based on its past velocity rather than by commitment. We develop an application that implements lots of workflows. We initially estimated many stories based on the premise that they would be harder to develop and our estimates considered that stories were not ordered (there are unfortunately some dependencies). It turns out that, now that we've implemented our first workflows, all other workflows will be very much easier to implement.

        The question was: shall we re-estimate the stories that deal with workflows that we plan before the sprint when we'll develop it? I saw two points in this question. First, why re-estimate and second, when re-estimate.

        Why re-estimate?
        • We learned something new about the story
        • We merged stories or split up stories (these are new stories so one cannot call it re-estimation I'd say)
        • The relative sizes of the stories changed
        • We screwed up in our estimates
        In this very case, the remaining workflow stories will take much less time to realise and therefore, I think that their relative sizes changed and we learned something new. 

        When re-estimate?
        • If we re-estimate the stories, we shall do it prior to the sprint, during a grooming session
        What is not clear is, if we re-estimated, should we re-estimate all the stories that are along the same lines and not those for the upcoming sprint? I would say yes because that would make the remaining estimates consistent and have a more reliable burn-down or burn-up.

        If we don't re-estimate:
        • The velocity will go through the roof when we implement those stories and the variations in velocity will be greater
        • The release plan will be less realistic and the range of story points to release will vary widely
        • We keep our estimates coherent with the past but less coherent for the future. New stories will be estimated as smaller even though relative sizes will be the same
        If we re-estimate:
        • We shall re-estimate all the workflow stories to keep them coherent
        • The velocity will remain stable
        • The release plan will be positively reviewed and allow us to take more in
        • We make our estimates for the future more coherent if we add any new story
        Could you please give me your advice/insights on why and when to re-estimate? For example,
        • Do you see any other reason why you'd recommend to re-estimate?
        • Do you think that we should re-estimate those stories? I would say yes
        • Do you think that we should re-estimate all affected stories or just those for the next sprint? I would say, re-estimate all the affected ones.

        Thanks in advance,

        Stephan



        --
        Thanks,
        Sarath.

        Quad One Technologies | Mobile: +91 98490 05629 | Off: +91 40 2335 0221 | www.quadone.com
      • Roy Morien
        You never screw up on your estimates. You are just uncertain about the future, and the complexity of the task. Screwing Up implies incompetence, or
        Message 3 of 13 , Jun 28, 2010
        • 0 Attachment
          You never 'screw up' on your estimates. You are just uncertain about the future, and the complexity of the task. 'Screwing Up' implies incompetence, or negligence. Were you incompetent or negligent, or were you just uncertain about the future, and the complexity of the task? Now, in hindsight, which means that you have learned something about the task, and you can see the situation with more certainty. 
           
          Regards,
          Roy Morien
           

          To: scrumdevelopment@yahoogroups.com
          From: kcsarath@...
          Date: Mon, 28 Jun 2010 18:50:27 +0530
          Subject: Re: [scrumdevelopment] Why and when re-estimate

           
          Hi Stephan,

                I agree with lot of the issues that you mention with re estimation. For me re estimation creates a moving target and a whole over head of reestimating stuff for consistency across the whole product back log.

               Why not look at a modified velocity based on your experience and it sort of has the same effect. If you see a lot of underestimates in your story points, your guesstimate of the velocity would be higher. But now that you realize that there is much more work than you initially estimated, try to see if a reduced velocity has the same effect of indicating that you previously under estimated the work and now can go slower than initially thought.

              If you had a lot of over estimates, you would see a converse effect on velocity and it should allow for the same correction.


               the goal of story points and the way we track release progress in the release burndown is to answer :

          1. How long is it going to take to finish all the stories in a release
          2. How many of the user stories can you finish by the end of a fixed time frame.
          Dont try to add too much more complexity to the use of story points. The most important piece is for the distance you assued the release would take now your velocity is lesser than initially expected or better than initially expected.

                So without having to go through the trouble of re-estimation of all story points in your release back log, just start a sprint, experience the velocity and see how things go ?



          thanks,
          Sarath.

          On Mon, Jun 28, 2010 at 5:08 PM, Stephan Huez <stephan.huez@ gmail.com> wrote:
           

          Hi,


          During the sprint planning meeting this morning, we had a discussion about whether or not to re-estimate some stories. 

          Our team plans its sprints based on its past velocity rather than by commitment. We develop an application that implements lots of workflows. We initially estimated many stories based on the premise that they would be harder to develop and our estimates considered that stories were not ordered (there are unfortunately some dependencies) . It turns out that, now that we've implemented our first workflows, all other workflows will be very much easier to implement.

          The question was: shall we re-estimate the stories that deal with workflows that we plan before the sprint when we'll develop it? I saw two points in this question. First, why re-estimate and second, when re-estimate.

          Why re-estimate?
          • We learned something new about the story
          • We merged stories or split up stories (these are new stories so one cannot call it re-estimation I'd say)
          • The relative sizes of the stories changed
          • We screwed up in our estimates
          In this very case, the remaining workflow stories will take much less time to realise and therefore, I think that their relative sizes changed and we learned something new. 

          When re-estimate?
          • If we re-estimate the stories, we shall do it prior to the sprint, during a grooming session
          What is not clear is, if we re-estimated, should we re-estimate all the stories that are along the same lines and not those for the upcoming sprint? I would say yes because that would make the remaining estimates consistent and have a more reliable burn-down or burn-up.

          If we don't re-estimate:
          • The velocity will go through the roof when we implement those stories and the variations in velocity will be greater
          • The release plan will be less realistic and the range of story points to release will vary widely
          • We keep our estimates coherent with the past but less coherent for the future. New stories will be estimated as smaller even though relative sizes will be the same
          If we re-estimate:
          • We shall re-estimate all the workflow stories to keep them coherent
          • The velocity will remain stable
          • The release plan will be positively reviewed and allow us to take more in
          • We make our estimates for the future more coherent if we add any new story
          Could you please give me your advice/insights on why and when to re-estimate? For example,
          • Do you see any other reason why you'd recommend to re-estimate?
          • Do you think that we should re-estimate those stories? I would say yes
          • Do you think that we should re-estimate all affected stories or just those for the next sprint? I would say, re-estimate all the affected ones.

          Thanks in advance,

          Stephan



          --
          Thanks,
          Sarath.

          Quad One Technologies | Mobile: +91 98490 05629 | Off: +91 40 2335 0221 | www.quadone. com



          Meet local singles online. Browse profiles for FREE!
        • Stephan Huez
          Hi Roy, You re right, I should have put it in another way. We definitely learned something, now we have to adapt. Regards, Stephan
          Message 4 of 13 , Jun 28, 2010
          • 0 Attachment
            Hi Roy,

            You're right, I should have put it in another way. We definitely learned something, now we have to adapt.

            Regards,

            Stephan

            On 29 June 2010 07:22, Roy Morien <roymorien@...> wrote:
             

            You never 'screw up' on your estimates. You are just uncertain about the future, and the complexity of the task. 'Screwing Up' implies incompetence, or negligence. Were you incompetent or negligent, or were you just uncertain about the future, and the complexity of the task? Now, in hindsight, which means that you have learned something about the task, and you can see the situation with more certainty. 


             
            Regards,
            Roy Morien
             

            To: scrumdevelopment@yahoogroups.com
            From: kcsarath@...
            Date: Mon, 28 Jun 2010 18:50:27 +0530
            Subject: Re: [scrumdevelopment] Why and when re-estimate

             
            Hi Stephan,

                  I agree with lot of the issues that you mention with re estimation. For me re estimation creates a moving target and a whole over head of reestimating stuff for consistency across the whole product back log.

                 Why not look at a modified velocity based on your experience and it sort of has the same effect. If you see a lot of underestimates in your story points, your guesstimate of the velocity would be higher. But now that you realize that there is much more work than you initially estimated, try to see if a reduced velocity has the same effect of indicating that you previously under estimated the work and now can go slower than initially thought.

                If you had a lot of over estimates, you would see a converse effect on velocity and it should allow for the same correction.


                 the goal of story points and the way we track release progress in the release burndown is to answer :

            1. How long is it going to take to finish all the stories in a release
            2. How many of the user stories can you finish by the end of a fixed time frame.
            Dont try to add too much more complexity to the use of story points. The most important piece is for the distance you assued the release would take now your velocity is lesser than initially expected or better than initially expected.

                  So without having to go through the trouble of re-estimation of all story points in your release back log, just start a sprint, experience the velocity and see how things go ?



            thanks,
            Sarath.

            On Mon, Jun 28, 2010 at 5:08 PM, Stephan Huez <stephan.huez@...> wrote:
             

            Hi,


            During the sprint planning meeting this morning, we had a discussion about whether or not to re-estimate some stories. 

            Our team plans its sprints based on its past velocity rather than by commitment. We develop an application that implements lots of workflows. We initially estimated many stories based on the premise that they would be harder to develop and our estimates considered that stories were not ordered (there are unfortunately some dependencies). It turns out that, now that we've implemented our first workflows, all other workflows will be very much easier to implement.

            The question was: shall we re-estimate the stories that deal with workflows that we plan before the sprint when we'll develop it? I saw two points in this question. First, why re-estimate and second, when re-estimate.

            Why re-estimate?
            • We learned something new about the story
            • We merged stories or split up stories (these are new stories so one cannot call it re-estimation I'd say)
            • The relative sizes of the stories changed
            • We screwed up in our estimates
            In this very case, the remaining workflow stories will take much less time to realise and therefore, I think that their relative sizes changed and we learned something new. 

            When re-estimate?
            • If we re-estimate the stories, we shall do it prior to the sprint, during a grooming session
            What is not clear is, if we re-estimated, should we re-estimate all the stories that are along the same lines and not those for the upcoming sprint? I would say yes because that would make the remaining estimates consistent and have a more reliable burn-down or burn-up.

            If we don't re-estimate:
            • The velocity will go through the roof when we implement those stories and the variations in velocity will be greater
            • The release plan will be less realistic and the range of story points to release will vary widely
            • We keep our estimates coherent with the past but less coherent for the future. New stories will be estimated as smaller even though relative sizes will be the same
            If we re-estimate:
            • We shall re-estimate all the workflow stories to keep them coherent
            • The velocity will remain stable
            • The release plan will be positively reviewed and allow us to take more in
            • We make our estimates for the future more coherent if we add any new story
            Could you please give me your advice/insights on why and when to re-estimate? For example,
            • Do you see any other reason why you'd recommend to re-estimate?
            • Do you think that we should re-estimate those stories? I would say yes
            • Do you think that we should re-estimate all affected stories or just those for the next sprint? I would say, re-estimate all the affected ones.

            Thanks in advance,

            Stephan




            --
            Thanks,
            Sarath.

            Quad One Technologies | Mobile: +91 98490 05629 | Off: +91 40 2335 0221 | www.quadone.com



            Meet local singles online. Browse profiles for FREE!


          • Stephan Huez
            Hi Sarath, Thanks for the advice. Actually, what we did was to not re-estimate anything during the planning meeting. Nevertheless, the question was raised. We
            Message 5 of 13 , Jun 28, 2010
            • 0 Attachment
              Hi Sarath,

              Thanks for the advice. 

              Actually, what we did was to not re-estimate anything during the planning meeting. Nevertheless, the question was raised. We planned based on the "overestimated" stories but we followed the yesterday's weather approach. I wanted to see how things would turn out if we kept our former estimates.

              On the other hand, I don't find much interest about the size of the stories once we're in a sprint and even for planning it. I have the sentiment that it might even be better not to think of them outside of release planning. What does really matter is, as you mentioned, to know where we are and where we are headed  with regard to the release. This is my current concern, hence my questions :)

              We'll see how things turn out when we end the sprint next week. We'll inspect and adapt again.

              Regards,

              Stephan

              On 28 June 2010 15:20, Sarath Kummamuru <kcsarath@...> wrote:
               

              Hi Stephan,

                    I agree with lot of the issues that you mention with re estimation. For me re estimation creates a moving target and a whole over head of reestimating stuff for consistency across the whole product back log.

                   Why not look at a modified velocity based on your experience and it sort of has the same effect. If you see a lot of underestimates in your story points, your guesstimate of the velocity would be higher. But now that you realize that there is much more work than you initially estimated, try to see if a reduced velocity has the same effect of indicating that you previously under estimated the work and now can go slower than initially thought.

                  If you had a lot of over estimates, you would see a converse effect on velocity and it should allow for the same correction.


                   the goal of story points and the way we track release progress in the release burndown is to answer :

              1. How long is it going to take to finish all the stories in a release
              2. How many of the user stories can you finish by the end of a fixed time frame.
              Dont try to add too much more complexity to the use of story points. The most important piece is for the distance you assued the release would take now your velocity is lesser than initially expected or better than initially expected.

                    So without having to go through the trouble of re-estimation of all story points in your release back log, just start a sprint, experience the velocity and see how things go ?



              thanks,
              Sarath.


              On Mon, Jun 28, 2010 at 5:08 PM, Stephan Huez <stephan.huez@...> wrote:
               

              Hi,


              During the sprint planning meeting this morning, we had a discussion about whether or not to re-estimate some stories. 

              Our team plans its sprints based on its past velocity rather than by commitment. We develop an application that implements lots of workflows. We initially estimated many stories based on the premise that they would be harder to develop and our estimates considered that stories were not ordered (there are unfortunately some dependencies). It turns out that, now that we've implemented our first workflows, all other workflows will be very much easier to implement.

              The question was: shall we re-estimate the stories that deal with workflows that we plan before the sprint when we'll develop it? I saw two points in this question. First, why re-estimate and second, when re-estimate.

              Why re-estimate?
              • We learned something new about the story
              • We merged stories or split up stories (these are new stories so one cannot call it re-estimation I'd say)
              • The relative sizes of the stories changed
              • We screwed up in our estimates
              In this very case, the remaining workflow stories will take much less time to realise and therefore, I think that their relative sizes changed and we learned something new. 

              When re-estimate?
              • If we re-estimate the stories, we shall do it prior to the sprint, during a grooming session
              What is not clear is, if we re-estimated, should we re-estimate all the stories that are along the same lines and not those for the upcoming sprint? I would say yes because that would make the remaining estimates consistent and have a more reliable burn-down or burn-up.

              If we don't re-estimate:
              • The velocity will go through the roof when we implement those stories and the variations in velocity will be greater
              • The release plan will be less realistic and the range of story points to release will vary widely
              • We keep our estimates coherent with the past but less coherent for the future. New stories will be estimated as smaller even though relative sizes will be the same
              If we re-estimate:
              • We shall re-estimate all the workflow stories to keep them coherent
              • The velocity will remain stable
              • The release plan will be positively reviewed and allow us to take more in
              • We make our estimates for the future more coherent if we add any new story
              Could you please give me your advice/insights on why and when to re-estimate? For example,
              • Do you see any other reason why you'd recommend to re-estimate?
              • Do you think that we should re-estimate those stories? I would say yes
              • Do you think that we should re-estimate all affected stories or just those for the next sprint? I would say, re-estimate all the affected ones.

              Thanks in advance,

              Stephan



              --
              Thanks,
              Sarath.

              Quad One Technologies | Mobile: +91 98490 05629 | Off: +91 40 2335 0221 | www.quadone.com


            • Steve Ropa
              Hi Stephan, If I understand correctly, you are talking about looking at stories in sprint planning that you previously estimated, perhaps in a product or
              Message 6 of 13 , Jun 29, 2010
              • 0 Attachment
                Hi Stephan,
                 
                If I understand correctly, you are talking about looking at stories in sprint planning that you previously estimated, perhaps in a product or release planning activity?  I like to revisit very briefly at sprint planning... "Hey gang, we estimated this as a 5 at release planning.  Based on what we've learned since then, does that still feel about right?"  More often than not, the number stays the same. 
                 
                Steve

                Sent: Monday, June 28, 2010 5:38 AM
                Subject: [scrumdevelopment] Why and when re-estimate

                 

                Hi,


                During the sprint planning meeting this morning, we had a discussion about whether or not to re-estimate some stories. 

                Our team plans its sprints based on its past velocity rather than by commitment. We develop an application that implements lots of workflows. We initially estimated many stories based on the premise that they would be harder to develop and our estimates considered that stories were not ordered (there are unfortunately some dependencies) . It turns out that, now that we've implemented our first workflows, all other workflows will be very much easier to implement.

                The question was: shall we re-estimate the stories that deal with workflows that we plan before the sprint when we'll develop it? I saw two points in this question. First, why re-estimate and second, when re-estimate.

                Why re-estimate?
                • We learned something new about the story
                • We merged stories or split up stories (these are new stories so one cannot call it re-estimation I'd say)
                • The relative sizes of the stories changed
                • We screwed up in our estimates
                In this very case, the remaining workflow stories will take much less time to realise and therefore, I think that their relative sizes changed and we learned something new. 

                When re-estimate?
                • If we re-estimate the stories, we shall do it prior to the sprint, during a grooming session
                What is not clear is, if we re-estimated, should we re-estimate all the stories that are along the same lines and not those for the upcoming sprint? I would say yes because that would make the remaining estimates consistent and have a more reliable burn-down or burn-up.

                If we don't re-estimate:
                • The velocity will go through the roof when we implement those stories and the variations in velocity will be greater
                • The release plan will be less realistic and the range of story points to release will vary widely
                • We keep our estimates coherent with the past but less coherent for the future. New stories will be estimated as smaller even though relative sizes will be the same
                If we re-estimate:
                • We shall re-estimate all the workflow stories to keep them coherent
                • The velocity will remain stable
                • The release plan will be positively reviewed and allow us to take more in
                • We make our estimates for the future more coherent if we add any new story
                Could you please give me your advice/insights on why and when to re-estimate? For example,
                • Do you see any other reason why you'd recommend to re-estimate?
                • Do you think that we should re-estimate those stories? I would say yes
                • Do you think that we should re-estimate all affected stories or just those for the next sprint? I would say, re-estimate all the affected ones.

                Thanks in advance,

                Stephan

              • Stephan Huez
                Hi Steve, Thanks for the suggestion. This is what we ll try to do as well. On the other hand, how often do you review your release plan in this case? In
                Message 7 of 13 , Jun 29, 2010
                • 0 Attachment
                  Hi Steve,

                  Thanks for the suggestion. This is what we'll try to do as well. 

                  On the other hand, how often do you review your release plan in this case? In practice, the impact of re-estimating the stories for a single sprint is low compared to the full scope and size of a release. Therefore, I would say that it isn't much of a problem.

                  Regards,

                  Stephan

                  On 29 June 2010 16:50, Steve Ropa <theropas@...> wrote:
                   

                  Hi Stephan,
                   
                  If I understand correctly, you are talking about looking at stories in sprint planning that you previously estimated, perhaps in a product or release planning activity?  I like to revisit very briefly at sprint planning... "Hey gang, we estimated this as a 5 at release planning.  Based on what we've learned since then, does that still feel about right?"  More often than not, the number stays the same. 
                   
                  Steve

                  Sent: Monday, June 28, 2010 5:38 AM
                  Subject: [scrumdevelopment] Why and when re-estimate

                   

                  Hi,


                  During the sprint planning meeting this morning, we had a discussion about whether or not to re-estimate some stories. 

                  Our team plans its sprints based on its past velocity rather than by commitment. We develop an application that implements lots of workflows. We initially estimated many stories based on the premise that they would be harder to develop and our estimates considered that stories were not ordered (there are unfortunately some dependencies). It turns out that, now that we've implemented our first workflows, all other workflows will be very much easier to implement.

                  The question was: shall we re-estimate the stories that deal with workflows that we plan before the sprint when we'll develop it? I saw two points in this question. First, why re-estimate and second, when re-estimate.

                  Why re-estimate?
                  • We learned something new about the story
                  • We merged stories or split up stories (these are new stories so one cannot call it re-estimation I'd say)
                  • The relative sizes of the stories changed
                  • We screwed up in our estimates
                  In this very case, the remaining workflow stories will take much less time to realise and therefore, I think that their relative sizes changed and we learned something new. 

                  When re-estimate?
                  • If we re-estimate the stories, we shall do it prior to the sprint, during a grooming session
                  What is not clear is, if we re-estimated, should we re-estimate all the stories that are along the same lines and not those for the upcoming sprint? I would say yes because that would make the remaining estimates consistent and have a more reliable burn-down or burn-up.

                  If we don't re-estimate:
                  • The velocity will go through the roof when we implement those stories and the variations in velocity will be greater
                  • The release plan will be less realistic and the range of story points to release will vary widely
                  • We keep our estimates coherent with the past but less coherent for the future. New stories will be estimated as smaller even though relative sizes will be the same
                  If we re-estimate:
                  • We shall re-estimate all the workflow stories to keep them coherent
                  • The velocity will remain stable
                  • The release plan will be positively reviewed and allow us to take more in
                  • We make our estimates for the future more coherent if we add any new story
                  Could you please give me your advice/insights on why and when to re-estimate? For example,
                  • Do you see any other reason why you'd recommend to re-estimate?
                  • Do you think that we should re-estimate those stories? I would say yes
                  • Do you think that we should re-estimate all affected stories or just those for the next sprint? I would say, re-estimate all the affected ones.

                  Thanks in advance,

                  Stephan


                • chuckspublicprofile
                  Stephan, ... There are infinite numbers of reasons to re-estimate, and those reasons are unimportant IMO. Here is the real reason: The team believes the
                  Message 8 of 13 , Jul 1, 2010
                  • 0 Attachment
                    Stephan,

                    > - Do you see any other reason why you'd recommend to re-estimate?
                    There are infinite numbers of reasons to re-estimate, and those reasons are unimportant IMO. Here is the real reason: The team believes the estimate for any future work needs to be re-discussed and/or re-estimated. On the other hand, I encourage teams not to waste a bunch of time discussing estimates ad nauseum.

                    > - Do you think that we should re-estimate those stories? I would say yes
                    Absolutely. I tell my teams they can re-estimate anytime they feel the need to, up until the point that a story is accepted into a sprint(some call this committing to a story). This acceptance usually happens at the end of a Sprint Planning Meeting, but can also happen mid-sprint when the team needs to take in more work. Note that this means even estimates can change right there in the Sprint Planning meeting.

                    > - Do you think that we should re-estimate all affected stories or just
                    > those for the next sprint? I would say, re-estimate all the affected ones.
                    Re-estimate any story that has not yet been accepted into a sprint. Do NOT re-estimate stories already completed or in progress. The one exception I might be ok with is if it was a team brand new to Scrum and they were near the end of their first 3 Sprints. I allow a one time re-estimation, and then only if it seems badly needed, but that rarely happens in my experience.







                    --- In scrumdevelopment@yahoogroups.com, Stephan Huez <stephan.huez@...> wrote:
                    >
                    > Hi,
                    >
                    > During the sprint planning meeting this morning, we had a discussion about
                    > whether or not to re-estimate some stories.
                    >
                    >
                    > Could you please give me your advice/insights on why and when to
                    > re-estimate? For example,
                    >
                    > - Do you see any other reason why you'd recommend to re-estimate?
                    > - Do you think that we should re-estimate those stories? I would say yes
                    > - Do you think that we should re-estimate all affected stories or just
                    > those for the next sprint? I would say, re-estimate all the affected ones.
                    >
                    >
                    > Thanks in advance,
                    >
                    > Stephan
                    >
                  • Stephan Huez
                    Hi Charles, Thanks for the advice. Don t worry about re-estimating completed stories, I wouldn t do that :) We learn from the past but can t change it. Cheers,
                    Message 9 of 13 , Jul 11, 2010
                    • 0 Attachment
                      Hi Charles,

                      Thanks for the advice. Don't worry about re-estimating completed stories, I wouldn't do that :) We learn from the past but can't change it.

                      Cheers,

                      Stephan

                      On 1 July 2010 20:12, chuckspublicprofile <chuck-lists2@...> wrote:
                       



                      Stephan,

                      > - Do you see any other reason why you'd recommend to re-estimate?
                      There are infinite numbers of reasons to re-estimate, and those reasons are unimportant IMO. Here is the real reason: The team believes the estimate for any future work needs to be re-discussed and/or re-estimated. On the other hand, I encourage teams not to waste a bunch of time discussing estimates ad nauseum.

                      > - Do you think that we should re-estimate those stories? I would say yes
                      Absolutely. I tell my teams they can re-estimate anytime they feel the need to, up until the point that a story is accepted into a sprint(some call this committing to a story). This acceptance usually happens at the end of a Sprint Planning Meeting, but can also happen mid-sprint when the team needs to take in more work. Note that this means even estimates can change right there in the Sprint Planning meeting.

                      > - Do you think that we should re-estimate all affected stories or just


                      > those for the next sprint? I would say, re-estimate all the affected ones.
                      Re-estimate any story that has not yet been accepted into a sprint. Do NOT re-estimate stories already completed or in progress. The one exception I might be ok with is if it was a team brand new to Scrum and they were near the end of their first 3 Sprints. I allow a one time re-estimation, and then only if it seems badly needed, but that rarely happens in my experience.


                      --- In scrumdevelopment@yahoogroups.com, Stephan Huez <stephan.huez@...> wrote:
                      >
                      > Hi,
                      >
                      > During the sprint planning meeting this morning, we had a discussion about
                      > whether or not to re-estimate some stories.
                      >
                      >
                      > Could you please give me your advice/insights on why and when to
                      > re-estimate? For example,
                      >
                      > - Do you see any other reason why you'd recommend to re-estimate?
                      > - Do you think that we should re-estimate those stories? I would say yes
                      > - Do you think that we should re-estimate all affected stories or just
                      > those for the next sprint? I would say, re-estimate all the affected ones.
                      >
                      >
                      > Thanks in advance,
                      >
                      > Stephan
                      >


                    • Roman Pieron
                      Hi, I would like to extend the discussion somehow in this way: What to do with the estimation in a case when a User Story was selected to the Sprint as usual
                      Message 10 of 13 , Jul 16, 2010
                      • 0 Attachment
                        Hi,

                        I would like to extend the discussion somehow in this way:

                        What to do with the estimation in a case when a User Story was selected to the Sprint as usual (we committed to complete it during Sprint) but at the end of Sprint it was not finished ? This US was not presented during Review meeting so we selected it into the next Sprint to complete it. Should we keep the original estimation (e.g. original 10 Story points) or should we re-estimate the rest of not-finished work at Sprint Planning Meeting (e.g. re-estimate to 2 Story points) ?

                        Guys decided not to re-estimate because they didn't want to lose 8 Story Points and influence the Velocity
                        My feeling is that this could be considered as "cheating" - Velocity is just metrics, not the goal so I expected that during the Planning meeting the Product Backlog will be updated according the actual and real situation => to complete that US in current Sprint we need only 2 Story Points.

                        What is your opinion in this special case ?

                        Thanks,
                        Roman


                        2010/7/1 chuckspublicprofile <chuck-lists2@...>
                         



                        Stephan,

                        > - Do you see any other reason why you'd recommend to re-estimate?
                        There are infinite numbers of reasons to re-estimate, and those reasons are unimportant IMO. Here is the real reason: The team believes the estimate for any future work needs to be re-discussed and/or re-estimated. On the other hand, I encourage teams not to waste a bunch of time discussing estimates ad nauseum.

                        > - Do you think that we should re-estimate those stories? I would say yes
                        Absolutely. I tell my teams they can re-estimate anytime they feel the need to, up until the point that a story is accepted into a sprint(some call this committing to a story). This acceptance usually happens at the end of a Sprint Planning Meeting, but can also happen mid-sprint when the team needs to take in more work. Note that this means even estimates can change right there in the Sprint Planning meeting.

                        > - Do you think that we should re-estimate all affected stories or just


                        > those for the next sprint? I would say, re-estimate all the affected ones.
                        Re-estimate any story that has not yet been accepted into a sprint. Do NOT re-estimate stories already completed or in progress. The one exception I might be ok with is if it was a team brand new to Scrum and they were near the end of their first 3 Sprints. I allow a one time re-estimation, and then only if it seems badly needed, but that rarely happens in my experience.


                        --- In scrumdevelopment@yahoogroups.com, Stephan Huez <stephan.huez@...> wrote:
                        >
                        > Hi,
                        >
                        > During the sprint planning meeting this morning, we had a discussion about
                        > whether or not to re-estimate some stories.
                        >
                        >
                        > Could you please give me your advice/insights on why and when to
                        > re-estimate? For example,
                        >
                        > - Do you see any other reason why you'd recommend to re-estimate?
                        > - Do you think that we should re-estimate those stories? I would say yes
                        > - Do you think that we should re-estimate all affected stories or just
                        > those for the next sprint? I would say, re-estimate all the affected ones.
                        >
                        >
                        > Thanks in advance,
                        >
                        > Stephan
                        >


                      • Prashant Pathak
                        I don t think it is cheating to NOT ReEstimate a 10 point story to a 2 point story in a new sprint! Re-estimating that would be cheating.The story points
                        Message 11 of 13 , Jul 16, 2010
                        • 0 Attachment
                          I don't think it is cheating to NOT ReEstimate a 10 point story to a 2 point
                          story in a new sprint! Re-estimating that would be cheating.The story points
                          should remain unchanged.


                          The reason is, the story points indicate the efforts required. So the efforts
                          required to finish it should be counted irrespective of what sprint it was
                          actually completed in.The story did take more than one sprint to finish and
                          warrants bigger story point number!!

                          Velocity should be measured over multiple sprints to get the real "Capacity".
                          Instantaneous velocity is misleading. IMHO.

                          In your special case, the earlier sprint will have less velocity and the next
                          one will have more...however, counting the efforts in both the sprints together
                          will be the actual measure of work-done.

                          Prashant
                        • extremeprogrammer
                          Hi. The reason some people measure velocity is so that they can predict something, e.g.: * How much stuff can we do in the next sprint? * How much longer is
                          Message 12 of 13 , Jul 17, 2010
                          • 0 Attachment
                            Hi.

                            The reason some people measure velocity is so that they can predict something, e.g.:

                            * How much stuff can we do in the next sprint?
                            * How much longer is the project going to take?

                            You need to adopt a *consistent* approach that lets you achieve whatever it is you're trying to achieve by measuring velocity and not worry whether it is 'cheating' or not. If it gives you the information you need, it's OK. You probably also need to give some consideration to whether the consistent approach you've chosen can be understood by everybody.

                            Regards,

                            Lance

                            --- In scrumdevelopment@yahoogroups.com, Roman Pieron <roman.pieron@...> wrote:
                            >
                            > Hi,
                            >
                            > I would like to extend the discussion somehow in this way:
                            >
                            > What to do with the estimation in a case when a User Story was selected to
                            > the Sprint as usual (we committed to complete it during Sprint) but at the
                            > end of Sprint it was not finished ? This US was not presented during Review
                            > meeting so we selected it into the next Sprint to complete it. Should we
                            > keep the original estimation (e.g. original 10 Story points) or should we
                            > re-estimate the rest of not-finished work at Sprint Planning Meeting (e.g.
                            > re-estimate to 2 Story points) ?
                            >
                            > Guys decided not to re-estimate because they didn't want to lose 8 Story
                            > Points and influence the Velocity
                            > My feeling is that this could be considered as "cheating" - Velocity is just
                            > metrics, not the goal so I expected that during the Planning meeting the
                            > Product Backlog will be updated according the actual and real situation =>
                            > to complete that US in current Sprint we need only 2 Story Points.
                            >
                            > What is your opinion in this special case ?
                            >
                            > Thanks,
                            > Roman
                            >
                            >
                            > 2010/7/1 chuckspublicprofile <chuck-lists2@...>
                            >
                            > >
                            > >
                            > >
                            > >
                            > > Stephan,
                            > >
                            > > > - Do you see any other reason why you'd recommend to re-estimate?
                            > > There are infinite numbers of reasons to re-estimate, and those reasons are
                            > > unimportant IMO. Here is the real reason: The team believes the estimate for
                            > > any future work needs to be re-discussed and/or re-estimated. On the other
                            > > hand, I encourage teams not to waste a bunch of time discussing estimates ad
                            > > nauseum.
                            > >
                            > > > - Do you think that we should re-estimate those stories? I would say yes
                            > > Absolutely. I tell my teams they can re-estimate anytime they feel the need
                            > > to, up until the point that a story is accepted into a sprint(some call this
                            > > committing to a story). This acceptance usually happens at the end of a
                            > > Sprint Planning Meeting, but can also happen mid-sprint when the team needs
                            > > to take in more work. Note that this means even estimates can change right
                            > > there in the Sprint Planning meeting.
                            > >
                            > > > - Do you think that we should re-estimate all affected stories or just
                            > >
                            > > > those for the next sprint? I would say, re-estimate all the affected
                            > > ones.
                            > > Re-estimate any story that has not yet been accepted into a sprint. Do NOT
                            > > re-estimate stories already completed or in progress. The one exception I
                            > > might be ok with is if it was a team brand new to Scrum and they were near
                            > > the end of their first 3 Sprints. I allow a one time re-estimation, and then
                            > > only if it seems badly needed, but that rarely happens in my experience.
                            > >
                            > >
                            > > --- In scrumdevelopment@yahoogroups.com<scrumdevelopment%40yahoogroups.com>,
                            > > Stephan Huez <stephan.huez@> wrote:
                            > > >
                            > > > Hi,
                            > > >
                            > > > During the sprint planning meeting this morning, we had a discussion
                            > > about
                            > > > whether or not to re-estimate some stories.
                            > > >
                            > > >
                            > > > Could you please give me your advice/insights on why and when to
                            > > > re-estimate? For example,
                            > > >
                            > > > - Do you see any other reason why you'd recommend to re-estimate?
                            > > > - Do you think that we should re-estimate those stories? I would say yes
                            > > > - Do you think that we should re-estimate all affected stories or just
                            > > > those for the next sprint? I would say, re-estimate all the affected
                            > > ones.
                            > > >
                            > > >
                            > > > Thanks in advance,
                            > > >
                            > > > Stephan
                            > > >
                            > >
                            > >
                            > >
                            >
                          • George Dinwiddie
                            Roman, ... This is not such a special case. Every new scrum team seems to go through this. I just had this discussion with a new scrummaster on Thursday.
                            Message 13 of 13 , Jul 17, 2010
                            • 0 Attachment
                              Roman,

                              On 7/16/10 11:28 AM, Roman Pieron wrote:
                              >
                              >
                              > Hi,
                              >
                              > I would like to extend the discussion somehow in this way:
                              >
                              > What to do with the estimation in a case when a User Story was selected
                              > to the Sprint as usual (we committed to complete it during Sprint) but
                              > at the end of Sprint it was not finished ? This US was not presented
                              > during Review meeting so we selected it into the next Sprint to complete
                              > it. Should we keep the original estimation (e.g. original 10 Story
                              > points) or should we re-estimate the rest of not-finished work at Sprint
                              > Planning Meeting (e.g. re-estimate to 2 Story points) ?
                              >
                              > Guys decided not to re-estimate because they didn't want to lose 8 Story
                              > Points and influence the Velocity
                              > My feeling is that this could be considered as "cheating" - Velocity is
                              > just metrics, not the goal so I expected that during the Planning
                              > meeting the Product Backlog will be updated according the actual and
                              > real situation => to complete that US in current Sprint we need only 2
                              > Story Points.
                              >
                              > What is your opinion in this special case ?

                              This is not such a special case. Every new scrum team seems to go
                              through this. I just had this discussion with a new scrummaster on
                              Thursday.

                              Story points are not something you collect. They're just a tool. The
                              primary purpose is to help you select the right amount of work for the
                              next sprint. You do that by counting only the work completed in the
                              previous sprint. If you also include work done in the sprint before
                              that, you'll continue to take on too much work. So, re-estimate.

                              The secondary purpose is for release planning. Here we're trying to
                              look way down the road. "If we're doing 20 points per sprint and we've
                              got about 160 points left in the backlog for this release, it'll take us
                              about 8 sprints to get done (or we'll have to adjust scope)." But that
                              20 is approximate. And that 160 is approximate. Therefore the 8 is
                              approximate. The 8 story points your team "doesn't want to lose" is
                              down in the noise level for this projection. Don't worry about it.

                              - George

                              --
                              ----------------------------------------------------------------------
                              * George Dinwiddie * http://blog.gdinwiddie.com
                              Software Development http://www.idiacomputing.com
                              Consultant and Coach http://www.agilemaryland.org
                              ----------------------------------------------------------------------
                            Your message has been successfully submitted and would be delivered to recipients shortly.