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

RE: [scrumdevelopment] Digest Number 144

Expand Messages
  • Jeff Sutherland
    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
    Message 1 of 4 , Aug 19 12:24 PM
    • 0 Attachment
      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
    • 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 2 of 4 , Aug 19 12:41 PM
      • 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 3 of 4 , Aug 19 8:41 PM
        • 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 4 of 4 , Aug 19 8:45 PM
          • 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.