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

How many product backlogs?

Expand Messages
  • scrumnoob
    Hello We are about to enter a period of product planning, that is we have high level visions for our software, those visions are basically different flavours
    Message 1 of 7 , Apr 29, 2010
    • 0 Attachment
      Hello

      We are about to enter a period of product planning, that is we have high level visions for our software, those visions are basically different flavours of the software for different markets. Behind the firewall versions with thick client, behind the firewall with thin client, hosted for smaller companies and a few other flavours.

      Some flavours will have different features, a lot of flavours will have common components to them, we also have a back log of features to be added for existing customers installations.

      My questions is, what strategies are available to me in terms of product backlog. I have, up to this point, worked on the basis that there should be only one backlog - and I still think that. But does anyone have any views that differ based on their experience? I have one team of 3 - 5 developers who will have to work on all features.

      I have read a fair bit of literature, but not found much on this.

      All help welcome.

      Sean
    • George Dinwiddie
      Hi, Sean ... One backlog, with the various flavors prioritized by the business. See, also,
      Message 2 of 7 , Apr 29, 2010
      • 0 Attachment
        Hi, Sean

        scrumnoob wrote:
        > Hello
        >
        > We are about to enter a period of product planning, that is we have
        > high level visions for our software, those visions are basically
        > different flavours of the software for different markets. Behind the
        > firewall versions with thick client, behind the firewall with thin
        > client, hosted for smaller companies and a few other flavours.
        >
        > Some flavours will have different features, a lot of flavours will
        > have common components to them, we also have a back log of features
        > to be added for existing customers installations.
        >
        > My questions is, what strategies are available to me in terms of
        > product backlog. I have, up to this point, worked on the basis that
        > there should be only one backlog - and I still think that. But does
        > anyone have any views that differ based on their experience? I have
        > one team of 3 - 5 developers who will have to work on all features.

        One backlog, with the various flavors prioritized by the business. See,
        also,
        http://blog.gdinwiddie.com/2007/12/03/combined-backlog-for-multiple-projects/

        - George

        --
        ----------------------------------------------------------------------
        * George Dinwiddie * http://blog.gdinwiddie.com
        Software Development http://www.idiacomputing.com
        Consultant and Coach http://www.agilemaryland.org
        ----------------------------------------------------------------------
      • Roman Pichler
        I would suggest you start small and develop your product for one market or market segment first before you create variants for other target groups. This will
        Message 3 of 7 , Apr 29, 2010
        • 0 Attachment
          I would suggest you start small and develop your product for one market or market segment first before you create variants for other target groups. This will not only mean that you can work with one product backlog and keep it concise but it also reduces your investment risk. Here are my thoughts on product planning in Scrum: http://bit.ly/d4TWMg

          Best wishes,

          Roman
          romanpichler.com

          *** New book Agile Product Management with Scrum out now! ***
          *** Next product owner class: London, 27-28 May ***

          --- In scrumdevelopment@yahoogroups.com, "scrumnoob" <scrumnoob@...> wrote:
          >
          > Hello
          >
          > We are about to enter a period of product planning, that is we have high level visions for our software, those visions are basically different flavours of the software for different markets. Behind the firewall versions with thick client, behind the firewall with thin client, hosted for smaller companies and a few other flavours.
          >
          > Some flavours will have different features, a lot of flavours will have common components to them, we also have a back log of features to be added for existing customers installations.
          >
          > My questions is, what strategies are available to me in terms of product backlog. I have, up to this point, worked on the basis that there should be only one backlog - and I still think that. But does anyone have any views that differ based on their experience? I have one team of 3 - 5 developers who will have to work on all features.
          >
          > I have read a fair bit of literature, but not found much on this.
          >
          > All help welcome.
          >
          > Sean
          >
        • Don MacIntyre
          Sounds like one product, one team, and one product owner to me.
          Message 4 of 7 , Apr 29, 2010
          • 0 Attachment
            Sounds like one product, one team, and one product owner to me.

            --- In scrumdevelopment@yahoogroups.com, "scrumnoob" <scrumnoob@...> wrote:
            >
            > Hello
            >
            > We are about to enter a period of product planning, that is we have high level visions for our software, those visions are basically different flavours of the software for different markets. Behind the firewall versions with thick client, behind the firewall with thin client, hosted for smaller companies and a few other flavours.
            >
            > Some flavours will have different features, a lot of flavours will have common components to them, we also have a back log of features to be added for existing customers installations.
            >
            > My questions is, what strategies are available to me in terms of product backlog. I have, up to this point, worked on the basis that there should be only one backlog - and I still think that. But does anyone have any views that differ based on their experience? I have one team of 3 - 5 developers who will have to work on all features.
            >
            > I have read a fair bit of literature, but not found much on this.
            >
            > All help welcome.
            >
            > Sean
            >
          • scrumnoob
            This is what I have defaulted to, well nearly. 1 team, 1 product (and therefore backlog). But I have 3 product owners to manage. Thanks for the feedback
            Message 5 of 7 , Apr 30, 2010
            • 0 Attachment
              This is what I have defaulted to, well nearly. 1 team, 1 product (and therefore backlog). But I have 3 "product owners" to manage.

              Thanks for the feedback all.

              --- In scrumdevelopment@yahoogroups.com, "Don MacIntyre" <don@...> wrote:
              >
              > Sounds like one product, one team, and one product owner to me.
              >
              > --- In scrumdevelopment@yahoogroups.com, "scrumnoob" <scrumnoob@> wrote:
              > >
              > > Hello
              > >
              > > We are about to enter a period of product planning, that is we have high level visions for our software, those visions are basically different flavours of the software for different markets. Behind the firewall versions with thick client, behind the firewall with thin client, hosted for smaller companies and a few other flavours.
              > >
              > > Some flavours will have different features, a lot of flavours will have common components to them, we also have a back log of features to be added for existing customers installations.
              > >
              > > My questions is, what strategies are available to me in terms of product backlog. I have, up to this point, worked on the basis that there should be only one backlog - and I still think that. But does anyone have any views that differ based on their experience? I have one team of 3 - 5 developers who will have to work on all features.
              > >
              > > I have read a fair bit of literature, but not found much on this.
              > >
              > > All help welcome.
              > >
              > > Sean
              > >
              >
            • Don MacIntyre
              ... Yep, been there, multiple or rotating product owners on one project is trouble. A little less painful if there is clearly one product owner in charge and
              Message 6 of 7 , May 1, 2010
              • 0 Attachment
                >>> But I have 3 "product owners" to manage.

                Yep, been there, multiple or rotating product owners on one project is trouble. A little less painful if there is clearly one product owner in charge and they are simply delegating work to other product owners.

                Always best to get to the point where you have 1 product owner managing the backlog and with you not having to manage any of them. ;)

                --- In scrumdevelopment@yahoogroups.com, "scrumnoob" <scrumnoob@...> wrote:
                >
                > This is what I have defaulted to, well nearly. 1 team, 1 product (and therefore backlog). But I have 3 "product owners" to manage.
                >
                > Thanks for the feedback all.
                >
                > --- In scrumdevelopment@yahoogroups.com, "Don MacIntyre" <don@> wrote:
                > >
                > > Sounds like one product, one team, and one product owner to me.
                > >
                > > --- In scrumdevelopment@yahoogroups.com, "scrumnoob" <scrumnoob@> wrote:
                > > >
                > > > Hello
                > > >
                > > > We are about to enter a period of product planning, that is we have high level visions for our software, those visions are basically different flavours of the software for different markets. Behind the firewall versions with thick client, behind the firewall with thin client, hosted for smaller companies and a few other flavours.
                > > >
                > > > Some flavours will have different features, a lot of flavours will have common components to them, we also have a back log of features to be added for existing customers installations.
                > > >
                > > > My questions is, what strategies are available to me in terms of product backlog. I have, up to this point, worked on the basis that there should be only one backlog - and I still think that. But does anyone have any views that differ based on their experience? I have one team of 3 - 5 developers who will have to work on all features.
                > > >
                > > > I have read a fair bit of literature, but not found much on this.
                > > >
                > > > All help welcome.
                > > >
                > > > Sean
                > > >
                > >
                >
              • Alex Reis
                Might be a little off-topic but still helpful to the OP: Last time we had to create a backlog from scratch, I found that iterating over the product backlog
                Message 7 of 7 , May 1, 2010
                • 0 Attachment
                  Might be a little off-topic but still helpful to the OP:

                  Last time we had to create a backlog from scratch, I found that iterating over the product backlog with the product owner really helps. For giving it some context, suppose we are creating the backlog for an eCommerce application.

                  1 - Come up with the different "modules" or bundles of functionality you expect your product to have. Example: Inventory Management, Front-end sales, Invoicing, Payment Processing, Product catalog management

                  2 - For each of those modules, create a separate card / sheet / wiki entry / whatever (We used wiki last time, works like a charm). Try to come up with finer grained functionality descriptions and fill them in. Example: [Inventory Management] As a user, I will be able to increase inventory quantities manually. Inventory decreases will happen automatically when an order is processed.

                  3 - Iterate over what you came up on step 2, dividing stories until the business value is no longer measurable if you split it. You don't need to go too fine grained either, as stories can also be broken down during iteration planning. Example:
                  [Inventory Management] As a user, I will be able to access the Inventory Management module after logging in
                  [Inventory Management] As a user, I will be able to review all transactions made in the inventory
                  [Inventory Management] As a user, I will be able to input invoices from suppliers and increase inventory
                  ... (Some 5-10 more)

                  4 - Have the team give a very coarse grained evaluation in number of points to each of the stories, to give the PO some idea on how hard they are to implement.

                  5 - Flatten the list of user stories by copying them from the individual cards / sheets / wiki pages to a single list.

                  6 - Prioritize the backlog, with the product owner. 

                  I found that one very helpful technique for that is playing a modified version of planning poker with at least the SM and the PO using one card for UP, one card for DOWN and one card for STAY.

                  You pick a story (I like to go bottom up from the order in the backlog, so that you don't tend to overrate the stories) and compare it to the one above it or below it, depending on the direction you choose. The participants play UP, meaning that the current story is higher priority than the next one, or DOWN meaning it's lower priority, or STAY meaning it is in the right place. Keep playing until you have some degree of consensus in STAY. Remember that when in doubt, the Product Owner is the one with the final word at all times.

                  This works for a certain number of stories, until the PO has more or less an idea of how the features group together, and whenever that happens you can abandon the cards and go with a more straightforward approach.

                  Hope I have given you some good input.

                  Best Regards,

                  Alexandre M. Reis
                  http://alexmreis.com
                  +32 472 787577


                  On Sat, May 1, 2010 at 11:26 AM, Don MacIntyre <don@...> wrote:
                   

                  >>> But I have 3 "product owners" to manage.

                  Yep, been there, multiple or rotating product owners on one project is trouble. A little less painful if there is clearly one product owner in charge and they are simply delegating work to other product owners.

                  Always best to get to the point where you have 1 product owner managing the backlog and with you not having to manage any of them. ;)

                  --- In scrumdevelopment@yahoogroups.com, "scrumnoob" <scrumnoob@...> wrote:
                  >
                  > This is what I have defaulted to, well nearly. 1 team, 1 product (and therefore backlog). But I have 3 "product owners" to manage.
                  >
                  > Thanks for the feedback all.
                  >
                  > --- In scrumdevelopment@yahoogroups.com, "Don MacIntyre" <don@> wrote:
                  > >
                  > > Sounds like one product, one team, and one product owner to me.
                  > >
                  > > --- In scrumdevelopment@yahoogroups.com, "scrumnoob" <scrumnoob@> wrote:
                  > > >
                  > > > Hello
                  > > >
                  > > > We are about to enter a period of product planning, that is we have high level visions for our software, those visions are basically different flavours of the software for different markets. Behind the firewall versions with thick client, behind the firewall with thin client, hosted for smaller companies and a few other flavours.
                  > > >
                  > > > Some flavours will have different features, a lot of flavours will have common components to them, we also have a back log of features to be added for existing customers installations.
                  > > >
                  > > > My questions is, what strategies are available to me in terms of product backlog. I have, up to this point, worked on the basis that there should be only one backlog - and I still think that. But does anyone have any views that differ based on their experience? I have one team of 3 - 5 developers who will have to work on all features.
                  > > >
                  > > > I have read a fair bit of literature, but not found much on this.
                  > > >
                  > > > All help welcome.
                  > > >
                  > > > Sean
                  > > >
                  > >
                  >


                Your message has been successfully submitted and would be delivered to recipients shortly.