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

Re: Why and when re-estimate

Expand Messages
  • 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 1 of 13 , Jul 1, 2010
      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 2 of 13 , Jul 11, 2010
        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 3 of 13 , Jul 16, 2010
          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 4 of 13 , Jul 16, 2010
            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 5 of 13 , Jul 17, 2010
              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 6 of 13 , Jul 17, 2010
                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.