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

Product Backlog questions

Expand Messages
  • gilmanj_2000@yahoo.com
    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
    Message 1 of 7 , Nov 29, 2001
      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
    • Ken Schwaber
      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
      Message 2 of 7 , Nov 30, 2001
        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@... [mailto:gilmanj_2000@...]
        Sent: Thursday, November 29, 2001 9:03 PM
        To: scrumdevelopment@yahoogroups.com
        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@...
        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
        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 3 of 7 , Nov 30, 2001
          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 4 of 7 , Nov 30, 2001
            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 5 of 7 , Nov 30, 2001
              <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 6 of 7 , Nov 30, 2001
                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 7 of 7 , 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!

                  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.