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

Master Backlog

Expand Messages
  • Ken Schwaber
    We ve encountered a new, useful type of backlog - master backlog. A product is driven by a product backlog, stating the features, facilities, content, and
    Message 1 of 1 , Aug 3, 2000
    • 0 Attachment
      We've encountered a new, useful type of backlog - master backlog.

      A product is driven by a product backlog, stating the features,
      facilities, content, and technology which the customer desires. The
      product manager maintains this list, and the customer determines the
      priority of the list, determining the order in which work will be
      performed.

      The priority of the list is a meld of what the user wants, when the
      user wants it, what is currently possible, what is required short
      term, and what is needed for long term competitive advantage. The
      customer works with the product manager to make these
      trade-off's,
      and then sets the priorities. Priorities change frequently.

      At the end of every Sprint, the team meets with the customer and
      demonstrates what they were able to build. Based on that, and with
      an eye toward the priorities, the customer and team select from the
      product backlog that which the team believes they can build during
      the next sprint. The customer has last word on what, the team has
      the last word on how much.

      The team then turns the Product backlog selected for the next sprint
      into a list of work that is required to create the deliverables
      indicated by the backlog and to meet the Sprint goal.

      A "Master backlog" of work, organized by product deliverable,
      defines
      what tasks have been required in the past to successfully build
      product backlog.

      The team selects the Master Backlog tasks appropriate for their
      product backlog. They then customize these to reflect the work that
      –
      in their circumstances – they expect to have to perform during
      the
      Sprint.

      During the daily Scrum meetings, the team will report on their
      progress regarding the Sprint Backlog list. Although they may find
      that they need to modify this list as they try to get their work done
      (who can anticipate everything?), in general their completion of the
      work on this list will result in the anticipated and agreed upon
      selected product backlog being ready to demonstrate at the end of the
      Sprint.

      The degree to which the team is able to select a product backlog that
      they can build during a Sprint, modify and adjust the Sprint Backlog
      list to reflect their actual work, and then deliver is tempered by
      their experience with the tools, the work environment, and having
      created identical product features and facilities in the past.
    Your message has been successfully submitted and would be delivered to recipients shortly.