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

RE: [scrumdevelopment] Re: SCRUM & Change / Defect Management

Expand Messages
  • Ayerst, Tom
    ... The issue is that the effort expended has no definitive relationship with the remaining estimate to complete (ETC), the number can even be negative, i.e.
    Message 1 of 23 , May 4, 2004
    • 0 Attachment
      > -----Original Message-----
      > From: Steve Bate [mailto:steve@...]
      >
      ...

      >
      > I'm curious why your developers are fine with daily updating of
      > their remaining time estimates but they fight tracking actual time
      > (again, for the purpose of calculating remaining time in the XPlanner
      > context).

      The issue is that the effort expended has no definitive relationship with
      the remaining estimate to complete (ETC), the number can even be negative,
      i.e. after a day of effort the task ETC may have increased. As we are
      focused on the planning aspect of the process (will we complete the selected
      work this Sprint?) the only thing we need to track is ETC, not actuals.
      Psychologically it is easier to re-estimate a larger ETC at the end of a
      days work than explicitly record the fact that your estimate was wrong or
      that you haven't worked hard/smart enough.

      >
      > > Hm. Is there any way to hack XPlanner in the meantime to get it to work
      > > the way you (and I) would expect it to work?
      >
      > See the messages referenced above.

      We are not using Xplanner yet but plan to simply update the ETC each day, as
      described on the Xplanner site. I would just like it to be as simple as
      updating the actuals (especially in the IDE plug-ins). Even better would be
      to be able to turn off the actuals completely.

      >
      > Eventually I'd like to extend XPlanner so that the planning and
      > tracking can be configured to handle a wide range of XP process
      > variants. This (and a Scrum-specific web skin) should also make
      > it an even better fit for Scrum teams.

      Cool idea. Once I've finished my house move I would like to help (Though
      that date is moving out two days per calendar day!)

      Cheers

      Tom


      --------------------------------------------------------------------------------
      The information contained herein is confidential and is intended solely for the
      addressee. Access by any other party is unauthorised without the express
      written permission of the sender. If you are not the intended recipient, please
      contact the sender either via the company switchboard on +44 (0)20 7623 8000, or
      via e-mail return. If you have received this e-mail in error or wish to read our
      e-mail disclaimer statement and monitoring policy, please refer to
      http://www.drkw.com/disc/email/ or contact the sender.
      --------------------------------------------------------------------------------
    • Steve Bate
      ... Hi Tom, Right, most teams use XPlanner to calculate ETC based on the task effort estimate and the actual time worked (ETC = estimate - actual). However,
      Message 2 of 23 , May 4, 2004
      • 0 Attachment
        > > I'm curious why your developers are fine with daily updating of
        > > their remaining time estimates but they fight tracking actual time
        > > (again, for the purpose of calculating remaining time in the XPlanner
        > > context).
        >
        > The issue is that the effort expended has no definitive relationship with
        > the remaining estimate to complete (ETC), the number can even be negative,
        > i.e. after a day of effort the task ETC may have increased.

        Hi Tom,

        Right, most teams use XPlanner to calculate ETC based on the task effort
        estimate and the actual time worked (ETC = estimate - actual). However,
        ETC in XPlanner is always equal or greater than zero. If the actual would
        exceed the estimated effort, a new (larger) estimate is requested. A task
        can be reestimated at any time. After reestimation, the ETC might be larger
        or smaller.

        > As we are
        > focused on the planning aspect of the process (will we complete
        > the selected work this Sprint?) the only thing we need to track is ETC,
        > not actuals. Psychologically it is easier to re-estimate a larger ETC at
        > the end of a days work than explicitly record the fact that your estimate
        > was wrong or that you haven't worked hard/smart enough.

        I wondered if that last issue might be one of the sources of resistance
        to recording actuals.

        Our team uses ETC to track intra-iteration (we're an XP team) status. We
        generally use previous actuals and estimation accuracy during our planning
        activities although a task that's been significantly reestimated during
        an iteration might trigger a related discussion in the standup meeting.

        For example, we learned that we tend to underestimate web development
        stories and the team determined it was because the functional tests were
        difficult to write. This motivated us to improve our web testing
        framework. Other stories would tend to run over because they depended
        on obtaining business information from our parent company and we
        were often passed to several intermediate people while obtaining the
        data. Once we noticed the trend of those stories exceeded estimates
        and determined why, we worked with the parent company to create more
        efficient ways to obtain the data we needed. I believe that having
        hard evidence of the impact of these inefficiencies decreases the
        response time in addressing them.

        Ken Schwaber discussed the pros and cons of tracking actuals in
        http://groups.yahoo.com/group/scrumdevelopment/message/2832.

        I agree with Ken that it's not a silver bullet. Still, we have found
        the extra feedback to be useful.

        >...
        > > Eventually I'd like to extend XPlanner so that the planning and
        > > tracking can be configured to handle a wide range of XP process
        > > variants. This (and a Scrum-specific web skin) should also make
        > > it an even better fit for Scrum teams.
        >
        > Cool idea. Once I've finished my house move I would like to help (Though
        > that date is moving out two days per calendar day!)

        :) I completely understand. I'm constantly doing a time balancing act
        between my myriad activities and working on XPlanner. Although the Scrum
        skin could be created immediately, the advanced configurability will require
        some significant internal refactoring over several releases. OTOH, even with
        the current implementation, the skin could present a view that only tracks
        ETC. Like I said in a previous message, I've never used XPlanner in this way
        but there shouldn't be any major problems. If there are small problems,
        I'd be happy to make those changes to better support Scrum teams.

        Regards,

        Steve
      • Mike Beedle
        Sometimes keeping actuals is not a choice , is a mandatory: http://groups.yahoo.com/group/scrumdevelopment/message/3300 mb ... From: Steve Bate
        Message 3 of 23 , May 4, 2004
        • 0 Attachment
          Message
          Sometimes keeping actuals is not a "choice", is a mandatory:
           
          mb


          -----Original Message-----
          From: Steve Bate [mailto:steve@...]
          Sent: Tuesday, May 04, 2004 9:20 AM
          To: scrumdevelopment@yahoogroups.com
          Subject: RE: [scrumdevelopment] Re: SCRUM & Change / Defect Management

          > > I'm curious why your developers are fine with daily updating of
          > > their remaining time estimates but they fight tracking actual time
          > > (again, for the purpose of calculating remaining time in the XPlanner
          > > context).
          >
          > The issue is that the effort expended has no definitive relationship with
          > the remaining estimate to complete (ETC), the number can even be negative,
          > i.e. after a day of effort the task ETC may have increased.

          Hi Tom,

          Right, most teams use XPlanner to calculate ETC based on the task effort
          estimate and the actual time worked (ETC = estimate - actual). However,
          ETC in XPlanner is always equal or greater than zero. If the actual would
          exceed the estimated effort, a new (larger) estimate is requested. A task
          can be reestimated at any time. After reestimation, the ETC might be larger
          or smaller.

          > As we are
          > focused on the planning aspect of the process (will we complete
          > the selected work this Sprint?) the only thing we need to track is ETC,
          > not actuals. Psychologically it is easier to re-estimate a larger ETC at
          > the end of a days work than explicitly record the fact that your estimate
          > was wrong or that you haven't worked hard/smart enough.

          I wondered if that last issue might be one of the sources of resistance
          to recording actuals.

          Our team uses ETC to track intra-iteration (we're an XP team) status. We
          generally use previous actuals and estimation accuracy during our planning
          activities although a task that's been significantly reestimated during
          an iteration might trigger a related discussion in the standup meeting.

          For example, we learned that we tend to underestimate web development
          stories and the team determined it was because the functional tests were
          difficult to write. This motivated us to improve our web testing
          framework. Other stories would tend to run over because they depended
          on obtaining business information from our parent company and we
          were often passed to several intermediate people while obtaining the
          data. Once we noticed the trend of those stories exceeded estimates
          and determined why, we worked with the parent company to create more
          efficient ways to obtain the data we needed. I believe that having
          hard evidence of the impact of these inefficiencies decreases the
          response time in addressing them.

          Ken Schwaber discussed the pros and cons of tracking actuals in
          http://groups.yahoo.com/group/scrumdevelopment/message/2832.

          I agree with Ken that it's not a silver bullet. Still, we have found
          the extra feedback to be useful.

          >...
          > > Eventually I'd like to extend XPlanner so that the planning and
          > > tracking can be configured to handle a wide range of XP process
          > > variants. This (and a Scrum-specific web skin) should also make
          > > it an even better fit for Scrum teams.
          >
          > Cool idea.  Once I've finished my house move I would like to help (Though
          > that date is moving out two days per calendar day!)

          :) I completely understand. I'm constantly doing a time balancing act
          between my myriad activities and working on XPlanner. Although the Scrum
          skin could be created immediately, the advanced configurability will require
          some significant internal refactoring over several releases. OTOH, even with
          the current implementation, the skin could present a view that only tracks
          ETC. Like I said in a previous message, I've never used XPlanner in this way
          but there shouldn't be any major problems. If there are small problems,
          I'd be happy to make those changes to better support Scrum teams.

          Regards,

          Steve




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


        • Deb
          Agreed. For many of us, time reporting is mandated - usually not for the functioning of the team itself, but for management. I m of two minds as to whether
          Message 4 of 23 , May 4, 2004
          • 0 Attachment
            Agreed. For many of us, time reporting is mandated - usually not for
            the functioning of the team itself, but for management.

            I'm of two minds as to whether it's a bad thing to record time spent
            and time remaining in the same tool...

            In Scrum, I work hard to convince developers that I REALLY REALLY
            mean it, when I say "upate your estimates to reflect *real* time
            remaining". They have trouble believing that I DO want them to
            increase estimates when needed. One thing I'm always saying (to get
            them to lose the old habit of under-estimating) is "I don't care
            about your actuals". I never come back to them about actuals, and
            eventually they believe me...

            If I ask them to put "time spent" into the same tool as "time
            remaining", it /looks/ like I might be tracking their actuals vs
            estimates... will this make them hedge on the "time remaining"
            figures?

            And on the other hand, it's more convenient than having to open 2
            tools...
            ???


            --- In scrumdevelopment@yahoogroups.com, "Mike Beedle" <beedlem@e...>
            wrote:
            > Sometimes keeping actuals is not a "choice", is a mandatory:
            > http://groups.yahoo.com/group/scrumdevelopment/message/3300
            >
            > mb
          • Doug Swartz
            ... Of course, you re right, sometimes actuals are necessary. I think the point that Tom is making is that it makes more sense to most developers (myself,
            Message 5 of 23 , May 4, 2004
            • 0 Attachment
              Tuesday, May 04, 2004, 10:54:17 AM, Mike Beedle wrote:

              > Sometimes keeping actuals is not a "choice", is a mandatory:
              > http://groups.yahoo.com/group/scrumdevelopment/message/3300

              Of course, you're right, sometimes actuals are necessary.

              I think the point that Tom is making is that it makes more
              sense to most developers (myself, anyway) to estimate a new
              Estimated Time to Completion than to update ETC by attempting
              to re-estimate the total task.





              --

              Doug Swartz
              daswartz@...
            • w6rabbit
              ... Steve, I ve appreciated your interacting on this. I see now, why you might want to track the original estimate for planning purposes at the next sprint
              Message 6 of 23 , May 6, 2004
              • 0 Attachment
                --- In scrumdevelopment@yahoogroups.com, Steve Bate <steve@x> wrote:
                > Joe and Brad,
                >
                >
                > Eventually I'd like to extend XPlanner so that the planning and
                > tracking can be configured to handle a wide range of XP process
                > variants. This (and a Scrum-specific web skin) should also make
                > it an even better fit for Scrum teams.
                >
                Steve,

                I've appreciated your interacting on this.
                I see now, why you might want to track the
                original estimate for planning purposes at
                the next sprint meeting.

                It turns out that it won't matter for me
                for a while. My head IT guy doens't want to
                install Apache on any of our servers.
                I'm not sure what that's about, and he has
                somewhat avoided the question. But I don't
                want to irk him over such a small thing.
                So look like we'll go a different direction.

                We've got Deb's spreadsheet and I think that
                will do us for a while anyway.

                BTW, while I'm wrapping up this subject,
                isn't there a way to provide a compiled version
                of the app for common OSs for those who don't
                want to set up a develpment environment to
                recompile it? Might widen your market a bit.

                Lastly, your required list only shows Ant,
                but my understanding is that Ant requires Apache.
                If so, you might want to list that up front
                as a requirement. My IT people were a bit
                put out after getting all the pieces on the
                (IIS) web server to find that it needed
                apache. They wished they had known that up front.

                Thanks,
                Brad.
              Your message has been successfully submitted and would be delivered to recipients shortly.