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

Re: How many product backlogs?

Expand Messages
  • 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 1 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 2 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 3 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.