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

RE: [scrumdevelopment] SCRUM tools (was process with other methodologies)

Expand Messages
  • Steve Bate
    ... Hi Eric, The focus of XPlanner tracking is actually on remaining time. The time tracking is used to determine the remaining time (estimate - actual). It s
    Message 1 of 9 , Apr 8, 2004
      > We actually tried using Xplanner and found the dissonance of terms and
      > measurements with Scrum to be a "muddying of the waters" as it
      > were--especially the accounting of time used for tasks. In Scrum, what's
      > more important is what time we have left, Xplanner wants to know how much
      > time you spent on the task. Two different ideas. This greatly
      > reduced the usefulness of the tool for our team. However, happy that
      > *you* found it useful!

      Hi Eric,

      The focus of XPlanner tracking is actually on remaining time. The time
      tracking is used to determine the remaining time (estimate - actual).
      It's also used for non-tracking purposes to obtain feedback on estimation
      inaccuracies (usually reviewed after an iteration/sprint).

      I've never tried it but I think it would work to never track time in
      XPlanner. You could only adjust your estimates downward (or upward)
      as you work a task or learn more about the true scope or whatever.
      I think the burndown chart would still be accurate with this
      technique. The downside is that you'd lose the feedback on estimation
      accuracies.

      I've considered creating a "skin" for XPlanner that is Scrum-specific.
      However, my experience is with XP. I'm not a CSM and haven't worked on
      a Scrum project (yet) so I'm not sure I'm well qualified.

      Regards,

      Steve
    • Eric Chamberlain
      Steve and all, My understainding of the Scrum concept is that a task starts with a given estimate as the time remaining and then that time remaining changes
      Message 2 of 9 , Apr 8, 2004
        Steve and all,

        My understainding of the Scrum concept is that a task starts with a given
        estimate as the "time remaining" and then that time remaining changes
        through the sprint. The goal is to have the time remaining be zero at the
        end of the sprint.
        Tracking the history to zero is the burndown chart (BTW, the burn-down chart
        feature of Xplanner never did work while we were using it). The burndown
        for a given sprint task can go up, stay constant, or go down. In Xplanner,
        it handles the latter two fairly well but the first requires a re-estimating
        of the task. That shouldn't be necessary.

        The time remaining for a task is not a calculated amount (estimated-done),
        it is the developer's perspective (always subjective) about how much more
        time it will require to accomplish that task. When I said "muddying the
        waters", this is the sort of thing I was talking about--burndown as a
        calculated value.

        Per-task burndown is actually a running task estimate. If I say I have 4
        hours left for a 20 hour task, that "4 hours" is an estimate (although
        probably pretty accurate in that range). If the next day I say I have 8
        hours left on that same task, that means that something didn't go right but
        it should not require that I re-estimate the task to 24 or 28 hours long. A
        Scrum tool should not require the task re-estimate, Xplanner does.

        == Eric ==

        -----Original Message-----
        From: Steve Bate [mailto:steve@...]
        Sent: Thursday, April 08, 2004 3:57 AM
        To: scrumdevelopment@yahoogroups.com
        Subject: RE: [scrumdevelopment] SCRUM tools (was process with other
        methodologies)

        > We actually tried using Xplanner and found the dissonance of terms and
        > measurements with Scrum to be a "muddying of the waters" as it
        > were--especially the accounting of time used for tasks. In Scrum,
        > what's more important is what time we have left, Xplanner wants to
        > know how much time you spent on the task. Two different ideas. This
        > greatly reduced the usefulness of the tool for our team. However,
        > happy that
        > *you* found it useful!

        Hi Eric,

        The focus of XPlanner tracking is actually on remaining time. The time
        tracking is used to determine the remaining time (estimate - actual).
        It's also used for non-tracking purposes to obtain feedback on estimation
        inaccuracies (usually reviewed after an iteration/sprint).

        I've never tried it but I think it would work to never track time in
        XPlanner. You could only adjust your estimates downward (or upward) as you
        work a task or learn more about the true scope or whatever.
        I think the burndown chart would still be accurate with this technique. The
        downside is that you'd lose the feedback on estimation accuracies.

        I've considered creating a "skin" for XPlanner that is Scrum-specific.
        However, my experience is with XP. I'm not a CSM and haven't worked on a
        Scrum project (yet) so I'm not sure I'm well qualified.

        Regards,

        Steve





        To Post a message, send it to: scrumdevelopment@...
        To Unsubscribe, send a blank message to:
        scrumdevelopment-unsubscribe@...
        Yahoo! Groups Links
      • Mike Beedle
        Eric: I respectfully disagree. If a developer says that it will take 4 more hours, you need to re-evaluate where you are i.e. re-estimate the original task.
        Message 3 of 9 , Apr 9, 2004
          Eric:

          I respectfully disagree. If a developer says that
          it will take 4 more hours, you need to re-evaluate
          where you are i.e. re-estimate the original task.

          On the day-2-day work, the "original estimate" doesn't
          need mean much -- it just got things started.
          What you need is clear picture, or the best picture
          you can get of "hours remaining" and trade-offs due
          to priority/capability.

          The cummulative effect across the board from the
          "picture taken" among all developers could
          send the overall estimates into a "danger zone".

          Btw, we use XPlanner and we like it a lot,

          - mb



          --- Eric Chamberlain <Eric.Chamberlain@...>
          wrote:

          Per-task burndown is actually a running task estimate.
          If I say I have 4
          hours left for a 20 hour task, that "4 hours" is an
          estimate (although
          probably pretty accurate in that range). If the next
          day I say I have 8
          hours left on that same task, that means that
          something didn't go right but
          it should not require that I re-estimate the task to
          24 or 28 hours long. A
          Scrum tool should not require the task re-estimate,
          Xplanner does.

          == Eric ==
        • Eric Chamberlain
          Mike: Hmmm. Seems like we agree and yet disagree. I am a bit confused. You agree with me that the original estimate doesn t mean much but then you think
          Message 4 of 9 , Apr 9, 2004
            Mike:

            Hmmm. Seems like we agree and yet disagree. I am a bit confused. You
            agree with me that the "original estimate" doesn't mean much but then you
            think it is fine that it needs to be changed if a task extends beyond its
            estimate. Why require change to something that doesn't mean much? You
            agree with me that the "hours remaining" provides the best picture of the
            situation--so is your happiness with Xplanner in *spite* of its requirement
            that you update relatively meaningless stats (the task estimates)? I think
            I must be missing something here or else I just have a lower irritation
            threshold w.r.t. the tools. In that case, we all agree on what is important,
            what Xplanner requires, and what busy work we're comfortable with in
            exchange for the benefits of the tool (and Xplanner *does* have benefits, to
            be sure).

            So if this is just a subjective thing, its probably best if this thread just
            dies here, eh?

            == Eric ==

            -----Original Message-----
            From: Mike Beedle [mailto:beedlem@...]
            Sent: Friday, April 09, 2004 5:24 AM
            To: scrumdevelopment@yahoogroups.com
            Subject: RE: [scrumdevelopment] SCRUM tools (was process with other method
            ologies)


            Eric:

            I respectfully disagree. If a developer says that it will take 4 more
            hours, you need to re-evaluate where you are i.e. re-estimate the original
            task.

            On the day-2-day work, the "original estimate" doesn't need mean much -- it
            just got things started.
            What you need is clear picture, or the best picture you can get of "hours
            remaining" and trade-offs due to priority/capability.

            The cummulative effect across the board from the "picture taken" among all
            developers could send the overall estimates into a "danger zone".

            Btw, we use XPlanner and we like it a lot,

            - mb



            --- Eric Chamberlain <Eric.Chamberlain@...>
            wrote:

            Per-task burndown is actually a running task estimate.
            If I say I have 4
            hours left for a 20 hour task, that "4 hours" is an estimate (although
            probably pretty accurate in that range). If the next day I say I have 8
            hours left on that same task, that means that something didn't go right but
            it should not require that I re-estimate the task to
            24 or 28 hours long. A
            Scrum tool should not require the task re-estimate, Xplanner does.

            == Eric ==




            ------------------------ Yahoo! Groups Sponsor ---------------------~--> Buy
            Ink Cartridges or Refill Kits for your HP, Epson, Canon or Lexmark Printer
            at MyInks.com. Free s/h on orders $50 or more to the US & Canada.
            http://www.c1tracking.com/l.asp?cid=5511
            http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/9EfwlB/TM
            ---------------------------------------------------------------------~->

            To Post a message, send it to: scrumdevelopment@...
            To Unsubscribe, send a blank message to:
            scrumdevelopment-unsubscribe@...
            Yahoo! Groups Links
          • Steve Bate
            ... a ... Hi Eric, Time remaining /can/ be a calculated amount but it s not required to be. The fact that it can be calculated makes it no less subjective (due
            Message 5 of 9 , Apr 9, 2004
              >...
              > The burndown for a given sprint task can go up, stay constant, or go down.
              > In Xplanner, it handles the latter two fairly well but the first requires
              a
              > re-estimating of the task. That shouldn't be necessary.
              >
              > The time remaining for a task is not a calculated amount (estimated-done),
              > it is the developer's perspective (always subjective) about how much more
              > time it will require to accomplish that task. When I said "muddying the
              > waters", this is the sort of thing I was talking about--burndown as a
              > calculated value.

              Hi Eric,

              Time remaining /can/ be a calculated amount but it's not required to
              be. The fact that it can be calculated makes it no less subjective (due
              the estimate used in the calculation). Did you understand what I was
              suggesting in the previous message? By never tracking actuals in XPlanner
              the "done" in the calculation is always zero. The task duration estimate
              effectively becomes the time remaining estimate (and the language
              translations could be modified accordingly).

              > Per-task burndown is actually a running task estimate.

              When you say "running estimate", do you mean an estimate that can change
              over time (i.e. a re-estimation of task remaining time)?

              > If I say I have 4 hours left for a 20 hour task, that "4 hours" is an
              > estimate (although probably pretty accurate in that range).

              If you used the technique I described and only cared about remaining
              time, the 20 hour duration estimate would be irrelevant. The remaining
              time estimate would be 4.

              > If the next day I say I have 8 hours left on that same task, that
              > means that something didn't go right but it should not require that
              > I re-estimate the task to 24 or 28 hours long. A Scrum tool should
              > not require the task re-estimate, Xplanner does.

              Right, in XPlanner you'd re-estimate the remaining time for the task
              to be 8. How do the Scrum-specific tools support this scenario?

              Regards,

              Steve
            • Mike Beedle
              Eric: You are right. Maybe we agree more than disagree. The only point I want to make is that in Scrum development we use time remaining to show the status
              Message 6 of 9 , Apr 9, 2004
                Eric:

                You are right. Maybe we agree more than disagree.

                The only point I want to make is that in Scrum
                development we use "time remaining" to
                show the status of the project i.e. it doesn't
                matter how much the team worked on something --
                what matters is how much work is left to do for the
                team.

                However, if you also have a "budgeting, reporting
                or costing control" need, knowing how much time
                things really took might also be important to you,
                the ScrmMaster and/or the Product Owner.

                This is where the "updated real time required" to
                accomplish something comes into play. The Scrum team
                typically cares less about this but it all depends
                on the situation. If you are working on a
                fix-bid contract, it matters. If you have a
                budget constraint, it matters. If you are working
                with internal/external resources that have cost
                associated with them, it matters, etc.

                - Mike

                Powder skiing is one of the best things in life...

                --- Eric Chamberlain <Eric.Chamberlain@...>
                wrote:

                ---------------------------------
                Mike:

                Hmmm. Seems like we agree and yet disagree. I am a
                bit confused. You
                agree with me that the "original estimate" doesn't
                mean much but then you
                think it is fine that it needs to be changed if a task
                extends beyond its
                estimate. Why require change to something that
                doesn't mean much? You
                agree with me that the "hours remaining" provides the
                best picture of the
                situation--so is your happiness with Xplanner in
                *spite* of its requirement
                that you update relatively meaningless stats (the task
                estimates)? I think
                I must be missing something here or else I just have a
                lower irritation
                threshold w.r.t. the tools. In that case, we all agree
                on what is important,
                what Xplanner requires, and what busy work we're
                comfortable with in
                exchange for the benefits of the tool (and Xplanner
                *does* have benefits, to
                be sure).

                So if this is just a subjective thing, its probably
                best if this thread just
                dies here, eh?

                == Eric ==

                -----Original Message-----
                From: Mike Beedle [mailto:beedlem@...]
                Sent: Friday, April 09, 2004 5:24 AM
                To: scrumdevelopment@yahoogroups.com
                Subject: RE: [scrumdevelopment] SCRUM tools (was
                process with other method
                ologies)


                Eric:

                I respectfully disagree. If a developer says that it
                will take 4 more
                hours, you need to re-evaluate where you are i.e.
                re-estimate the original
                task.

                On the day-2-day work, the "original estimate" doesn't
                need mean much -- it
                just got things started.
                What you need is clear picture, or the best picture
                you can get of "hours
                remaining" and trade-offs due to priority/capability.

                The cummulative effect across the board from the
                "picture taken" among all
                developers could send the overall estimates into a
                "danger zone".

                Btw, we use XPlanner and we like it a lot,

                - mb



                --- Eric Chamberlain <Eric.Chamberlain@...>
                wrote:

                Per-task burndown is actually a running task estimate.
                If I say I have 4
                hours left for a 20 hour task, that "4 hours" is an
                estimate (although
                probably pretty accurate in that range). If the next
                day I say I have 8
                hours left on that same task, that means that
                something didn't go right but
                it should not require that I re-estimate the task to
                24 or 28 hours long. A
                Scrum tool should not require the task re-estimate,
                Xplanner does.

                == Eric ==




                ------------------------ Yahoo! Groups Sponsor
                ---------------------~--> Buy
                Ink Cartridges or Refill Kits for your HP, Epson,
                Canon or Lexmark Printer
                at MyInks.com. Free s/h on orders $50 or more to the
                US & Canada.
                http://www.c1tracking.com/l.asp?cid=5511
                http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/9EfwlB/TM
                ---------------------------------------------------------------------~->

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






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


                Yahoo! Groups Sponsor ADVERTISEMENT


                ---------------------------------
                Yahoo! Groups Links

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

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

                Your use of Yahoo! Groups is subject to the Yahoo!
                Terms of Service.
              • Eric Chamberlain
                Steve, Oh, Your paragraph on ignoring the progress (included below) explained a lot! No, I hadn t caught that before. I can see now how XPLanner could be
                Message 7 of 9 , Apr 12, 2004
                  Steve,

                  Oh, Your paragraph on ignoring the progress (included below) explained a
                  lot! No, I hadn't caught that before.
                  I can see now how XPLanner could be useful when you skip certain features
                  like that.

                  Thanks.

                  == Eric ==


                  -----Original Message-----
                  From: Steve Bate [mailto:steve@...]
                  Sent: Friday, April 09, 2004 2:29 PM
                  To: scrumdevelopment@yahoogroups.com
                  Subject: RE: [scrumdevelopment] SCRUM tools (was process with other
                  methodologies)

                  >...
                  Time remaining /can/ be a calculated amount but it's not required to be. The
                  fact that it can be calculated makes it no less subjective (due the estimate
                  used in the calculation). Did you understand what I was suggesting in the
                  previous message? By never tracking actuals in XPlanner the "done" in the
                  calculation is always zero. The task duration estimate effectively becomes
                  the time remaining estimate (and the language translations could be modified
                  accordingly).
                  >...
                Your message has been successfully submitted and would be delivered to recipients shortly.