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

RE: [scrumdevelopment] Digest Number 144

Expand Messages
  • 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 1 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.
      -----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

      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:

      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.