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

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

Expand Messages
  • J. B. Rainsberger
    ... How big are your tasks? So big that writing 6 hours (= 1 day) and 12 hours (= 2 days) is a hardship? (In my world, 1 day = 6 hours, and not 8. I ve never
    Message 1 of 23 , May 1, 2004
    • 0 Attachment
      w6rabbit wrote:

      > We're half way through our first official sprint,
      > and starting to look at how to track time remaining
      > so that it is visible to stakeholders.
      >
      > My confusion with XPlanner (cute name) is that
      > it seems to assume
      > a) that my task estimates are in hours;

      How big are your tasks? So big that writing 6 hours (= 1 day) and 12
      hours (= 2 days) is a hardship? (In my world, 1 day = 6 hours, and not
      8. I've never got 8 good hours of work in a day done, especially when
      pairing.)

      > b) that programmers track their time on
      > each task, as opposed to doing multiple
      > things during the day.

      I don't know anything about XPlanner, but my understanding is that to
      track time on a task, all that matters is "how much more time do you
      need to finish?" In that sense, doing multiple things during the day
      ought not to affect tracking this status.

      > I can imagine requiring each to re-estimate
      > the units left on a task, but it's hard to
      > imagine getting them to track their time
      > daily without a fight.

      At the end of the day, they look at the two or three tasks they're
      working on (this is an advanced practice, by the way -- one things at a
      time is best) and estimate how much they have left to do, then update
      that information. You have to fight them to do this? It takes less than
      one minute per task.
      --
      J. B. Rainsberger,
      Diaspar Software Services
      http://www.diasparsoftware.com :: +1 416 791-8603
      Let's write software that people understand
    • w6rabbit
      ... to ... you ... day ... JB, thanks for replying. This is exactly my point. I only want them to re-estimate how much time is remaining and not get caught up
      Message 2 of 23 , May 3, 2004
      • 0 Attachment
        --- In scrumdevelopment@yahoogroups.com, "J. B. Rainsberger"
        <jbrains@r...> wrote:
        > w6rabbit wrote:
        >
        >
        > > b) that programmers track their time on
        > > each task, as opposed to doing multiple
        > > things during the day.
        >
        > I don't know anything about XPlanner, but my understanding is that
        to
        > track time on a task, all that matters is "how much more time do
        you
        > need to finish?" In that sense, doing multiple things during the
        day
        > ought not to affect tracking this status.


        JB, thanks for replying.

        This is exactly my point.
        I only want them to re-estimate how much
        time is remaining and not get caught up
        in "how much time did I spend on this."
        But that does not appear, to me, to be
        how XPlanner works.

        For something that I took to be specifically
        tailored for XP, that seemed very odd to me.
        I assume I'm misunderstanding something.
        >
        > > I can imagine requiring each to re-estimate
        > > the units left on a task, but it's hard to
        > > imagine getting them to track their time
        > > daily without a fight.
        >
        > At the end of the day, they look at the two or three tasks they're
        > working on (this is an advanced practice, by the way -- one things
        at a
        > time is best) and estimate how much they have left to do, then
        update
        > that information. You have to fight them to do this? It takes less
        than
        > one minute per task.

        No. They are fine with this. It was
        XPlanner that I was confused on.

        Thanks,
        Brad.
      • J. B. Rainsberger
        ... ... I understand a bit better now. XPlanner expects you to track time spent rather than time remaining? ... I would venture over to the
        Message 3 of 23 , May 3, 2004
        • 0 Attachment
          w6rabbit wrote:
          > --- In scrumdevelopment@yahoogroups.com, "J. B. Rainsberger"
          > <jbrains@r...> wrote:
          >
          >>w6rabbit wrote:
          >>

          <snip />
          > This is exactly my point.
          > I only want them to re-estimate how much
          > time is remaining and not get caught up
          > in "how much time did I spend on this."
          > But that does not appear, to me, to be
          > how XPlanner works.

          I understand a bit better now. XPlanner expects you to track time spent
          rather than time remaining?

          > For something that I took to be specifically
          > tailored for XP, that seemed very odd to me.
          > I assume I'm misunderstanding something.

          I would venture over to the extremeprogramming list and ask them about
          it. They have experience with XPlanner that I don't have.

          >>>I can imagine requiring each to re-estimate
          >>>the units left on a task, but it's hard to
          >>>imagine getting them to track their time
          >>>daily without a fight.
          >>
          >>At the end of the day, they look at the two or three tasks they're
          >>working on (this is an advanced practice, by the way -- one things
          > at a
          >>time is best) and estimate how much they have left to do, then
          > update
          >>that information. You have to fight them to do this? It takes less
          > than
          >>one minute per task.
          >
          > No. They are fine with this. It was
          > XPlanner that I was confused on.

          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?

          Good luck.

          (And people wonder why I stick with index cards and a wiki.)
          --
          J. B. Rainsberger,
          Diaspar Software Services
          http://www.diasparsoftware.com :: +1 416 791-8603
          Let's write software that people understand
        • Eric Chamberlain
          I participated in an earlier thread in this group about Xplanner. I have not been a fan of it for Scrum since it is XP-oriented but in the earlier thread, it
          Message 4 of 23 , May 3, 2004
          • 0 Attachment
            I participated in an earlier thread in this group about Xplanner. I have
            not been a fan of it for Scrum since it is XP-oriented but in the earlier
            thread, it was explained to me that Xplanner can actually work out fine AS
            LONG AS you ignore the daily task work additions feature and just adjust the
            task length (i.e. the task-specific burndown).

            In this case, less is more. Not using the daily Xplanner feature to log
            progress means that you are left with the simplicity of just the time-left
            in the task.

            HTH.

            == Eric ==

            -----Original Message-----
            From: J. B. Rainsberger [mailto:jbrains@...]
            Sent: Monday, May 03, 2004 12:19 PM
            To: scrumdevelopment@yahoogroups.com
            Subject: Re: [scrumdevelopment] Re: SCRUM & Change / Defect Management

            w6rabbit wrote:
            > --- In scrumdevelopment@yahoogroups.com, "J. B. Rainsberger"
            > <jbrains@r...> wrote:
            >
            >>w6rabbit wrote:
            >>

            <snip />
            > This is exactly my point.
            > I only want them to re-estimate how much time is remaining and not get
            > caught up in "how much time did I spend on this."
            > But that does not appear, to me, to be how XPlanner works.

            I understand a bit better now. XPlanner expects you to track time spent
            rather than time remaining?

            > For something that I took to be specifically tailored for XP, that
            > seemed very odd to me.
            > I assume I'm misunderstanding something.

            I would venture over to the extremeprogramming list and ask them about it.
            They have experience with XPlanner that I don't have.

            >>>I can imagine requiring each to re-estimate the units left on a task,
            >>>but it's hard to imagine getting them to track their time daily
            >>>without a fight.
            >>
            >>At the end of the day, they look at the two or three tasks they're
            >>working on (this is an advanced practice, by the way -- one things
            > at a
            >>time is best) and estimate how much they have left to do, then
            > update
            >>that information. You have to fight them to do this? It takes less
            > than
            >>one minute per task.
            >
            > No. They are fine with this. It was XPlanner that I was confused on.

            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?

            Good luck.

            (And people wonder why I stick with index cards and a wiki.)
            --
            J. B. Rainsberger,
            Diaspar Software Services
            http://www.diasparsoftware.com :: +1 416 791-8603 Let's write software that
            people understand



            To Post a message, send it to: scrumdevelopment@...
            To Unsubscribe, send a blank message to:
            scrumdevelopment-unsubscribe@...
            Yahoo! Groups Links
          • Steve Bate
            ... Joe and Brad, See... http://groups.yahoo.com/group/scrumdevelopment/message/3273 http://groups.yahoo.com/group/scrumdevelopment/message/3295 and related
            Message 5 of 23 , May 3, 2004
            • 0 Attachment
              > From: "J. B. Rainsberger" <jbrains@...>
              > w6rabbit wrote:
              > <snip />
              > > This is exactly my point.
              > > I only want them to re-estimate how much
              > > time is remaining and not get caught up
              > > in "how much time did I spend on this."
              > > But that does not appear, to me, to be
              > > how XPlanner works.
              >
              > I understand a bit better now. XPlanner expects you to track time spent
              > rather than time remaining?

              Joe and Brad,

              See...

              http://groups.yahoo.com/group/scrumdevelopment/message/3273
              http://groups.yahoo.com/group/scrumdevelopment/message/3295

              and related messages in a recent thread on this topic.

              > > For something that I took to be specifically
              > > tailored for XP, that seemed very odd to me.
              > > I assume I'm misunderstanding something.
              >...

              I'm not sure why that's an odd XP feature. IIRC (I don't have the
              book in front of me right now) the Planning Extreme Programming book
              shows examples of time tracking.

              > >>>I can imagine requiring each to re-estimate
              > >>>the units left on a task, but it's hard to
              > >>>imagine getting them to track their time
              > >>>daily without a fight.
              > >>
              >...
              > >>that information. You have to fight them to do this? It takes less
              > > than one minute per task.
              > >
              > > No. They are fine with this. It was
              > > XPlanner that I was confused on.

              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).

              > 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.

              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.

              Regards,

              Steve
            • 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 6 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 7 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 8 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 9 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 10 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 11 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.