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

"Dont' keep a backlog at all."---Ron Jeffries

Expand Messages
  • Mike Cohn
    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
    Message 1 of 2 , Aug 18, 2002
    • 0 Attachment
      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
    • mpoppendieck
      ... XPMagazine ... Hi Mike, I don t think Ron and I have the same vision of a backlog. I used to program the control systems for new machines to made tape at
      Message 2 of 2 , Aug 19, 2002
      • 0 Attachment
        --- In scrumdevelopment@y..., "Mike Cohn" <mike@m...> wrote:
        > 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.

        Hi Mike,

        I don't think Ron and I have the same vision of a backlog.

        I used to program the control systems for new machines to made tape
        at 3M. Pretty much standard practice was to develop a punch list at
        the end of a major installation. It was basically an agreement that
        once these items were punched off, the job would be done. The punch
        list was prioritized by the customer, and worked on in more less
        priority order by the installation team, until it was done. That is
        how I see a backlog.

        The important thing about a punch list is that the customer is
        comfortable that all of their concerns about the installation will
        eventually get addressed, while the team has a tool to help the
        customer to set priorities and a good way to know when they will
        really be done.

        This is how I view the backlog. Ron's metaphor of a king with a
        bunch of subjects, the king making priority decisions on the
        subject's requests, doesn't reflect (for me) the concept of a
        punch list or the purpose it serves. A punch list is a wonderful
        device, widely used and understood. I'll bet if you ever had a
        house built or remodeled, you tied up the ends of the contract with
        a punch list.

        Mary Poppendieck
        www.poppendieck.com
      Your message has been successfully submitted and would be delivered to recipients shortly.