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

143RE: [scrumdevelopment] Re: Product Backlog questions

Expand Messages
  • Ken Schwaber
    Nov 30, 2001
      Great, You get to write the backlog chapters of the next book!

      -----Original Message-----
      From: gilmanj_2000@... [mailto:gilmanj_2000@...]
      Sent: Friday, November 30, 2001 2:41 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Re: Product Backlog questions

      Now I think I get it!


      --- In scrumdevelopment@y..., "Ken Schwaber" <ken.schwaber@v...>
      > <First, you say that "the 'current product backlog' represents work
      > that will be done against the rooot of the source library."
      > I was under the impression that the product backlog represented both
      > work that will be done and work that "might" be done. However,
      > release backlogs and sprint backlogs represented only work to be
      > done. Is that incorrect?>
      > Product Backlog is a single list of work that might be done.
      > indicate where we think the next Sprint might come from, the Sprint
      > that, etc., and another separator indicate that moment's plans for
      the next
      > release. But the order and the separators move around as the
      > changes its mind because of market conditions or project progress.
      > product backlog is completed in a Sprint, it is removed from the
      > backlog (already done), or when it is selected for and being worked
      on in a
      > current Sprint, it is marked and doesn't move until the end of the
      > (when some of it might be not completed and need to be reentered
      into the
      > Product Backlog. Sprint backlog is a separate list, and the only
      > separate list of work.
      > <Second, how do you represent what is workable versus unworkable in
      > the product backlog, or are you saying that items are moved out of
      > the product backlog onto a release backlog and/or(?) sprint backlog,
      > and not simply replicated in these lists, and it is at this point
      > that said work becomes workable because you don't move items to
      > lists until you have put a sufficient level of thought to how they
      > will be done?>
      > Put a flag in a product backlog columns ... completed, pending,
      > sprint, issue. The issues are unworkable backlog because they need
      to be
      > turned into work.
      > <<.S. I think this adds to my earlier comment that a valuable
      > to the book would be sample artifacts showing their contents and
      > relationships to each other>
      > I agree.
      > Ken
      > > The current product backlog represents work that will be done
      > against the
      > > current root of the source library. Major functional,
      > and
      > > design flaws are represented in this list, along with new
      > functionality.
      > > Like, we need to add additional indices to the workflow system
      > because of
      > > performance problems. Issues are in the product backlog, but they
      > don't yet
      > > represent work (unworkable backlog). For instance, an issue might
      > be that
      > > the workflow has inadequate performance for the volume of expected
      > usage.
      > > This isn't yet work (unworkable), but when it is thought about and
      > the work
      > > that will address it known (add more indices), the issue is
      > and the
      > > work (indices) is in the backlog.
      > >
      > To Post a message, send it to: scrumdevelopment@e...
      > To Unsubscribe, send a blank message to:
      > scrumdevelopment-unsubscribe@e...
      > Your use of Yahoo! Groups is subject to

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

      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    • Show all 7 messages in this topic