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

RE: [scrumdevelopment] Digest Number 144

Expand Messages
  • John Brewer
    ... How about for an in-house IS department? Say they are constantly getting unrelated requests like add this field to employee in the payroll system ,
    Message 1 of 4 , Aug 19, 2002
    • 0 Attachment
      > However, other backlogs need to be maintained properly by support and
      > product marketing in order to properly tee up the next Sprint.

      How about for an in-house IS department? Say they are constantly
      getting unrelated requests like "add this field to employee in the
      payroll system", "produce this new report for ERP", "add a contest
      registration section to the public website", etc. Petition the king
      might be a good way to allocate resources for things like that.

      John Brewer
      Jera Design

      Extreme Programming FAQ: http://www.jera.com/techinfo/xpfaq.html
    • Mike Cohn
      That s a good point, John. In that case the cost of re-creating the list of backlog items each period might very likely be less than the cost of errantly doing
      Message 2 of 4 , Aug 19, 2002
      • 0 Attachment
        That's a good point, John.
         
        In that case the cost of re-creating the list of backlog items each period might very likely be less than the cost of errantly doing some work (e.g., producing the ERP report even though the requestor no longer needs it).
         
        I thought Mary's analogy to a punch list was appropriate. I would have been extremely frustrated if my builder came back to me each morning and made me do a daily walkthrough with him and "petition the king" for each change.
         
        --Mike
        -----Original Message-----
        From: John Brewer [mailto:jbrewer@...]
        Sent: Monday, August 19, 2002 1:41 PM
        To: scrumdevelopment@yahoogroups.com
        Subject: RE: [scrumdevelopment] Digest Number 144

        > However, other backlogs need to be maintained properly by support and
        > product marketing in order to properly tee up the next Sprint.

        How about for an in-house IS department?  Say they are constantly
        getting unrelated requests like "add this field to employee in the
        payroll system", "produce this new report for ERP", "add a contest
        registration section to the public website", etc.  Petition the king
        might be a good way to allocate resources for things like that.

        John Brewer
        Jera Design

        Extreme Programming FAQ: http://www.jera.com/techinfo/xpfaq.html


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


        Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
      • Mike Cohn
        Yes, the sprint backlog is definitely the most important. I try to not even let developers know much about changes to the product backlog during the
        Message 3 of 4 , Aug 19, 2002
        • 0 Attachment
          Yes, the "sprint backlog" is definitely the most important. I try to not even let developers know much about changes to the product backlog during the sprint--there's no point making them think about backlog items that could either go away or get prioritized lower. So, yes, in that sense the only backlog that really matters is the sprint backlog.
           
          I understood Ron's article to essentially be advocating that everyone stop there--no support backlog or marketing backlog is maintained. On many of the projects I've worked on we have very large product backlogs and small sprint backlogs. For example, one current project I'm on has 30 or so sprint backlog items and about 100 on the product backlog (about 2/3rds we'll do, the rest are dreams). I would really hate to recreate that list each sprint. I found Ron's article interesting to think about in terms of Scrum backlogs but I find that the effort of tracking backlog to be so simple and so useful that I don't plan to stop doing it.
           
          --Mike
          -----Original Message-----
          From: Jeff Sutherland [mailto:jeff.sutherland@...]
          Sent: Monday, August 19, 2002 1:24 PM
          To: 'scrumdevelopment@yahoogroups.com'
          Subject: RE: [scrumdevelopment] Digest Number 144

          Mike,
          The critical backlog I look for is the backlog that must be completed for
          this Sprint to close, since we almost always go directly to a short
          QA/Release cycle and ship it. If the backlog cannot be closed for this
          Sprint, we can't ship.

          The Product Manager makes the calls on backlog in consultation with the
          SCRUM. He integrates backlogs from customers that are maintained by the
          support organization, his own backlog of product commitments, the backlog of
          bugs and enhancements that didn't get in the previous release.

          So from the developers point of view, they only want to know the committed
          backlog for the current Sprint. In that sense I agree with Ron Jeffries.
          However, other backlogs need to be maintained properly by support and
          product marketing in order to properly tee up the next Sprint.

          Jeff Sutherland


          Message: 1
             Date: Sun, 18 Aug 2002 21:19:57 -0600
             From: "Mike Cohn" <mike@...>
          Subject: "Dont' keep a backlog at all."---Ron Jeffries

          I saw this interesting article recently on Ron Jeffries on his XPMagazine
          site. In it he suggests "don't keep a backlog at all."

          I'm interested in what others think.

          I think it's a horrible idea.

          The cost of creating the backlog is not something you want to go through
          every sprint/iteration. The cost of wrongly doing an item on the backlog
          that a user would not have "petitioned" for in a later sprint (but that you
          did thinking he would) is likely to be less than the cost of recreating the
          backlog each sprint.

          At a minimum, it's interesting reading and I'd like to hear what other
          Scrummers think.

          Here's the link to the article:
          http://www.xprogramming.com/xpmag/PetitionTheKing.htm




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


          Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
        Your message has been successfully submitted and would be delivered to recipients shortly.