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

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

Expand Messages
  • 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 1 of 9 , Apr 9, 2004
    • 0 Attachment
      >...
      > 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 2 of 9 , Apr 9, 2004
      • 0 Attachment
        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 3 of 9 , Apr 12, 2004
        • 0 Attachment
          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.