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

Re: Product Backlog questions

Expand Messages
  • gilmanj_2000@yahoo.com
    Thank, Ken We do maintain bugs in a seperate list, for some reason I came to the conclusion that everything was supposed to go into the product backlog and
    Message 1 of 7 , Nov 30, 2001
    • 0 Attachment
      Thank, Ken

      We do maintain bugs in a seperate list, for some reason I came to the
      conclusion that everything was supposed to go into the product
      backlog and this obviously would create a problem.

      John

      --- In scrumdevelopment@y..., "Ken Schwaber" <ken.schwaber@v...>
      wrote:
      > So we enter the realm of source code libraries, version control and
      release
      > control.
      >
      > Source libraries usually have a main root that is being worked on
      for new
      > releases. Older releases represent code branches of older source.
      Builds are
      > tied to the various nodes on the source tree by numbering schemes
      or other
      > mechanisms.
      >
      > A release, represented by a branch on the source code tree, is
      represented
      > by a build, a set of source code, and a bug list. Different
      companies have
      > different policies on updating and rereleasing the build, so that
      known
      > problems are fixed (but new functionality is not included). This is
      > obviously easier with web/server based products that client/server
      based
      > products. The bug list for a release may be worked on a % of the
      time by the
      > product team, or sometimes by a separate "maintenance" or "customer
      support"
      > team. Either way, it represents a separate code base. Good
      engineering
      > practices dictate that code fixed in older releases is brought
      forward into
      > the most current code base, though, where new development is
      occurring.
      > Anyway, I'm indicating that the release bug list is not a backlog
      list.
      > However, every release consists of product backlog that has been
      turned into
      > functionality and is no longer on the current product backlog.
      >
      > The current product backlog represents work that will be done
      against the
      > current root of the source library. Major functional, architectural
      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 removed
      and the
      > work (indices) is in the backlog.
      >
      > If the product backlog list is hard to maintain and understand it
      becomes
      > unusable. Simplify. Summarize. Keep bugs out of it. The most
      important,
      > highest priority backlog is the most granular and detailed, the
      stuff more
      > than three months out is mostly indicative.
      >
      > Hope this helps.
      > Ken
      >
      > -----Original Message-----
      > From: gilmanj_2000@y... [mailto:gilmanj_2000@y...]
      > Sent: Thursday, November 29, 2001 9:03 PM
      > To: scrumdevelopment@y...
      > Subject: [scrumdevelopment] Product Backlog questions
      >
      >
      > Ken,
      >
      > I have a couple of questions about the Product Backlog.
      >
      > Assuming that I allow everything into this backlog, I am concerned
      > about having so many rows that I struggle to prioritize it over
      > time. Feature requests aren't bad because they generally are fairly
      > abstract, but how do you handle lots of rows? An example of the
      sorts
      > of things that might get added are "Correct spelling
      > of "successfully" on screen X."
      >
      > Do you allow other's to add directly to the backlog and you
      > periodically go in prioritize and add time estimates, or do you add
      > rows yourself and insert them where you think they best fit?
      >
      > Page 34 refers to "unworkable" Product Backlog. Is this a seperate
      > list or something else?
      >
      > Finally, do you ever maintain other backlogs (beyond Product,
      > Release, Sprint), or does this actually make life harder? For
      > example, lets say I have lots of spelling errors in my UI. Is it
      > best to have each instance in the Product backlog as a row or
      > abstract to a single row, "Correct Spelling Errors in UI," and
      > maintain a seperate "Spelling Errors Backlog?"
      >
      > Thanks,
      > John Gilman
      >
      >
      > 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
      http://docs.yahoo.com/info/terms/
    • gilmanj_2000@yahoo.com
      Couple of follow ups. First, you say that the current product backlog represents work that will be done against the rooot of the source library. I was
      Message 2 of 7 , Nov 30, 2001
      • 0 Attachment
        Couple of follow ups.

        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?

        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 these
        lists until you have put a sufficient level of thought to how they
        will be done?

        Hope this makes sense.

        P.S. I think this adds to my earlier comment that a valuable addition
        to the book would be sample artifacts showing their contents and
        relationships to each other.

        John

        --- In scrumdevelopment@y..., "Ken Schwaber" <ken.schwaber@v...>

        . . .

        > The current product backlog represents work that will be done
        against the
        > current root of the source library. Major functional, architectural
        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 removed
        and the
        > work (indices) is in the backlog.
        >
      • Ken Schwaber
        Message 3 of 7 , Nov 30, 2001
        • 0 Attachment
          <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. Separators
          indicate where we think the next Sprint might come from, the Sprint after
          that, etc., and another separator indicate that moment's plans for the next
          release. But the order and the separators move around as the business
          changes its mind because of market conditions or project progress. As
          product backlog is completed in a Sprint, it is removed from the product
          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 Sprint
          (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 other
          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 these
          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, current
          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 addition
          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, architectural
          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 removed
          and the
          > work (indices) is in the backlog.
          >



          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 http://docs.yahoo.com/info/terms/
        • gilmanj_2000@yahoo.com
          Now I think I get it! John ... Separators ... after ... the next ... business ... As ... product ... on in a ... Sprint ... into the ... other ... these ...
          Message 4 of 7 , Nov 30, 2001
          • 0 Attachment
            Now I think I get it!

            John

            --- In scrumdevelopment@y..., "Ken Schwaber" <ken.schwaber@v...>
            wrote:
            >
            > <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.
            Separators
            > indicate where we think the next Sprint might come from, the Sprint
            after
            > that, etc., and another separator indicate that moment's plans for
            the next
            > release. But the order and the separators move around as the
            business
            > changes its mind because of market conditions or project progress.
            As
            > product backlog is completed in a Sprint, it is removed from the
            product
            > 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
            Sprint
            > (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
            other
            > 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
            these
            > 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,
            current
            > 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
            addition
            > 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,
            architectural
            > 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
            removed
            > 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
            http://docs.yahoo.com/info/terms/
          • Ken Schwaber
            Great, You get to write the backlog chapters of the next book! ... From: gilmanj_2000@yahoo.com [mailto:gilmanj_2000@yahoo.com] Sent: Friday, November 30, 2001
            Message 5 of 7 , Nov 30, 2001
            • 0 Attachment
              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!

              John

              --- In scrumdevelopment@y..., "Ken Schwaber" <ken.schwaber@v...>
              wrote:
              >
              > <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.
              Separators
              > indicate where we think the next Sprint might come from, the Sprint
              after
              > that, etc., and another separator indicate that moment's plans for
              the next
              > release. But the order and the separators move around as the
              business
              > changes its mind because of market conditions or project progress.
              As
              > product backlog is completed in a Sprint, it is removed from the
              product
              > 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
              Sprint
              > (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
              other
              > 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
              these
              > 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,
              current
              > 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
              addition
              > 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,
              architectural
              > 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
              removed
              > 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
              http://docs.yahoo.com/info/terms/


              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 http://docs.yahoo.com/info/terms/
            Your message has been successfully submitted and would be delivered to recipients shortly.