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

Single backlog per team

Expand Messages
  • gzgruber
    Mates, Our teams sometimes have multiple projects. I am wondering what is the best way and what is the SCRUM way of handling this. My feeling is that the best
    Message 1 of 10 , Dec 2, 2007
    • 0 Attachment
      Mates,

      Our teams sometimes have multiple projects. I am wondering what is the
      best way and what is the SCRUM way of handling this. My feeling is that
      the best way is to have a single backlog per team (even if this means
      that in a sprint the team is working on backlog items belonging to
      multiple projects). I think the purists will recommend splitting the
      team and having multiple backlogs.

      Any thoughts on this would be greatly appreciated

      BR,

      Gilad
    • Mike Vizdos
      What does the team think? Thank you, Mike Www.implementingscrum.com Www.michaelvizdos.com
      Message 2 of 10 , Dec 2, 2007
      • 0 Attachment
        What does the team think?

        Thank you,

        Mike


        On Dec 2, 2007, at 10:13 AM, "gzgruber" <gilad.gruber@...> wrote:

        Mates,

        Our teams sometimes have multiple projects. I am wondering what is the
        best way and what is the SCRUM way of handling this. My feeling is that
        the best way is to have a single backlog per team (even if this means
        that in a sprint the team is working on backlog items belonging to
        multiple projects). I think the purists will recommend splitting the
        team and having multiple backlogs.

        Any thoughts on this would be greatly appreciated

        BR,

        Gilad

      • Joakim Karlsson
        ... Ideally, I think it s best to have one team working on one project only. That said, I guess it could work to have one backlog spanning several projects.
        Message 3 of 10 , Dec 2, 2007
        • 0 Attachment
          On Dec 2, 2007 4:13 PM, gzgruber <gilad.gruber@...> wrote:
          >
          > Our teams sometimes have multiple projects. I am wondering what is the
          > best way and what is the SCRUM way of handling this. My feeling is that

          Ideally, I think it's best to have one team working on one project
          only. That said, I guess it could work to have one backlog spanning
          several projects. But I think that would require that you have the
          same PO for all projects. Someone that can prioritize all work for the
          team.

          --
          Regards,
          Joakim Karlsson
          http://www.jkarlsson.com/blog
        • gzgruber
          Hi Tim, Team is OK with this, it prevent the fragmentation BR, Gilad ... is the ... is ... means ... the
          Message 4 of 10 , Dec 2, 2007
          • 0 Attachment
            Hi Tim,

            Team is OK with this, it prevent the fragmentation

            BR,

            Gilad

            --- In scrumdevelopment@yahoogroups.com, Mike Vizdos <mvizdos@...>
            wrote:
            >
            > What does the team think?
            >
            > Thank you,
            >
            > Mike
            > Www.implementingscrum.com
            > Www.michaelvizdos.com
            >
            >
            > On Dec 2, 2007, at 10:13 AM, "gzgruber" <gilad.gruber@...> wrote:
            >
            > > Mates,
            > >
            > > Our teams sometimes have multiple projects. I am wondering what
            is the
            > > best way and what is the SCRUM way of handling this. My feeling
            is
            > > that
            > > the best way is to have a single backlog per team (even if this
            means
            > > that in a sprint the team is working on backlog items belonging to
            > > multiple projects). I think the purists will recommend splitting
            the
            > > team and having multiple backlogs.
            > >
            > > Any thoughts on this would be greatly appreciated
            > >
            > > BR,
            > >
            > > Gilad
            > >
            > >
            > >
            >
          • kaverjody
            Hi Gilad, I think your backlog means product backlog , right? Then I against the idea of having a single product backlog per team. First, product owner is
            Message 5 of 10 , Dec 2, 2007
            • 0 Attachment
              Hi Gilad,

              I think your "backlog" means "product backlog", right?

              Then I against the idea of having a single product backlog per team.
              First, product owner is the person who can decide the format of
              product backlog. And basically I think you do not have a single
              product owner for different projects. Second, the product backlog is
              constructing based on priority, how you construct the product backlog
              among projects? Then you mess up the backlog with project priority,
              which not directly relate to customer requirement priority.

              Based on the assumption you have to work on different projects in
              same sprint, my suggestion is :

              You should have your team's capacity estimated, then perhaps you need
              to negotiate with project managers about capacity division among
              projects. Then use your project specific capacity to select product
              backlog items for different projects.

              Best Regards,
              Xu Yi-Kaveri


              --- In scrumdevelopment@yahoogroups.com, "gzgruber"
              <gilad.gruber@...> wrote:
              >
              > Mates,
              >
              > Our teams sometimes have multiple projects. I am wondering what is
              the
              > best way and what is the SCRUM way of handling this. My feeling is
              that
              > the best way is to have a single backlog per team (even if this
              means
              > that in a sprint the team is working on backlog items belonging to
              > multiple projects). I think the purists will recommend splitting
              the
              > team and having multiple backlogs.
              >
              > Any thoughts on this would be greatly appreciated
              >
              > BR,
              >
              > Gilad
              >
            • Roy Morien
              Given that a project is really just a collection of apparently associated activities, probably intending to achieve a common outcome, then I think that is
              Message 6 of 10 , Dec 2, 2007
              • 0 Attachment
                Given that a 'project' is really just a collection of apparently associated activities, probably intending to achieve a common outcome, then I think that is what should be in the Product Backlog. If there are other activities that have no relevant association, then perhaps they should be in another Product Backlog.
                 
                I think one major influence on this is to do with the changeover effort and setup time needed for team members to move from one activity to another. It is clearly inefficient and wasteful if the team is moved to something else that has no relevance to what they are currently doing. Perhaps this is the benchmark that you should apply to deciding your 'projects' and the associated Product Backlog.
                 
                Of course, for those teams that are predominantly doing maintenance and 'on request' type development, where service requests come in almost on adhoc or asynchronous basis, then there may be no escaping the need for such changeover and setup times, and everything goes into a common Product Backlog.
                 
                But in all of this, common sense must prevail, surely. If it is convenient and efficient to have many teams, each with its own PB, then fine, go for it. Each PB will have to be separately prioritised. If a common backlog that is shared by many teams, then that implies that many teams, of appropriate numbers each (7-9 maximum) share the same PB, and then it just becomes a problem of handling the prioritising of the PB, AND of the orderly selecting of items to go onto the various Sprint Backlogs.
                 
                Yes?  No?
                 
                Regards,
                Roy Morien.





                To: scrumdevelopment@yahoogroups.com
                From: yi.xu@...
                Date: Mon, 3 Dec 2007 05:46:20 +0000
                Subject: [scrumdevelopment] Re: Single backlog per team

                Hi Gilad,

                I think your "backlog" means "product backlog", right?

                Then I against the idea of having a single product backlog per team.
                First, product owner is the person who can decide the format of
                product backlog. And basically I think you do not have a single
                product owner for different projects. Second, the product backlog is
                constructing based on priority, how you construct the product backlog
                among projects? Then you mess up the backlog with project priority,
                which not directly relate to customer requirement priority.

                Based on the assumption you have to work on different projects in
                same sprint, my suggestion is :

                You should have your team's capacity estimated, then perhaps you need
                to negotiate with project managers about capacity division among
                projects. Then use your project specific capacity to select product
                backlog items for different projects.

                Best Regards,
                Xu Yi-Kaveri

                --- In scrumdevelopment@ yahoogroups. com, "gzgruber"
                <gilad.gruber@ ...> wrote:
                >
                > Mates,
                >
                > Our teams sometimes have multiple projects. I am wondering what is
                the
                > best way and what is the SCRUM way of handling this. My feeling is
                that
                > the best way is to have a single backlog per team (even if this
                means
                > that in a sprint the team is working on backlog items belonging to
                > multiple projects). I think the purists will recommend splitting
                the
                > team and having multiple backlogs.
                >
                > Any thoughts on this would be greatly appreciated
                >
                > BR,
                >
                > Gilad
                >




                Check our comprehensive Salary Centre Overpaid or Underpaid?
              • Wolfgang Schulze Zachau
                That is the way we handle this situation. We have one team and one product backlog covering a variety of projects. There is one product owner and he is the
                Message 7 of 10 , Dec 3, 2007
                • 0 Attachment
                  That is the way we handle this situation. We have one team and one product backlog covering a variety of projects. There is one product owner and he is the ultimate decider on priorities, after careful consultation with the customers and other stakeholders. Works well, as long as the PO is left to make his own decisions. As soon as he is meddled with, things tend to go astray. We (as a company) have learned from that and now he is mostly left alone. Of course, you need thr right kind of guy to be PO. Somebody who is truly impartial and cannot be bought. And he needs a bit of brains.
                   

                  Regards,

                  Wolfgang

                   


                  From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Joakim Karlsson
                  Sent: 02 December 2007 16:29
                  To: scrumdevelopment@yahoogroups.com
                  Subject: Re: [scrumdevelopment] Single backlog per team

                  On Dec 2, 2007 4:13 PM, gzgruber <gilad.gruber@ gmail.com> wrote:
                  >
                  > Our teams sometimes have multiple projects. I am wondering what is the
                  > best way and what is the SCRUM way of handling this. My feeling is that

                  Ideally, I think it's best to have one team working on one project
                  only. That said, I guess it could work to have one backlog spanning
                  several projects. But I think that would require that you have the
                  same PO for all projects. Someone that can prioritize all work for the
                  team.

                  --
                  Regards,
                  Joakim Karlsson
                  http://www.jkarlsso n.com/blog

                • gzgruber
                  Hi Wolfgang, This is indeed the state I would like. We do have 1 PO for multiple projects and it seems like the correct way to handle. BR, G ... product ...
                  Message 8 of 10 , Dec 3, 2007
                  • 0 Attachment
                    Hi Wolfgang,

                    This is indeed the state I would like. We do have 1 PO for multiple
                    projects and it seems like the correct way to handle.

                    BR,

                    G

                    --- In scrumdevelopment@yahoogroups.com, "Wolfgang Schulze Zachau"
                    <wolfgang@...> wrote:
                    >
                    > That is the way we handle this situation. We have one team and one
                    product
                    > backlog covering a variety of projects. There is one product owner
                    and he is
                    > the ultimate decider on priorities, after careful consultation with
                    the
                    > customers and other stakeholders. Works well, as long as the PO is
                    left to
                    > make his own decisions. As soon as he is meddled with, things tend
                    to go
                    > astray. We (as a company) have learned from that and now he is
                    mostly left
                    > alone. Of course, you need thr right kind of guy to be PO. Somebody
                    who is
                    > truly impartial and cannot be bought. And he needs a bit of brains.
                    >
                    >
                    > Regards,
                    >
                    > Wolfgang
                    >
                    >
                    >
                    >
                    > _____
                    >
                    > From: scrumdevelopment@yahoogroups.com
                    > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Joakim
                    Karlsson
                    > Sent: 02 December 2007 16:29
                    > To: scrumdevelopment@yahoogroups.com
                    > Subject: Re: [scrumdevelopment] Single backlog per team
                    >
                    >
                    >
                    > On Dec 2, 2007 4:13 PM, gzgruber <gilad.gruber@
                    > <mailto:gilad.gruber%40gmail.com> gmail.com> wrote:
                    > >
                    > > Our teams sometimes have multiple projects. I am wondering what
                    is the
                    > > best way and what is the SCRUM way of handling this. My feeling
                    is that
                    >
                    > Ideally, I think it's best to have one team working on one project
                    > only. That said, I guess it could work to have one backlog spanning
                    > several projects. But I think that would require that you have the
                    > same PO for all projects. Someone that can prioritize all work for
                    the
                    > team.
                    >
                    > --
                    > Regards,
                    > Joakim Karlsson
                    > http://www.jkarlsso <http://www.jkarlsson.com/blog> n.com/blog
                    >
                  • George Dinwiddie
                    ... Surely the Product Owner (or Product Owner Team, if it s multiple individuals) *can* prioritize a single backlog that encompasses multiple projects. Can
                    Message 9 of 10 , Dec 3, 2007
                    • 0 Attachment
                      kaverjody wrote:
                      > Hi Gilad,
                      >
                      > I think your "backlog" means "product backlog", right?
                      >
                      > Then I against the idea of having a single product backlog per team.
                      > First, product owner is the person who can decide the format of
                      > product backlog. And basically I think you do not have a single
                      > product owner for different projects. Second, the product backlog is
                      > constructing based on priority, how you construct the product backlog
                      > among projects? Then you mess up the backlog with project priority,
                      > which not directly relate to customer requirement priority.

                      Surely the Product Owner (or Product Owner Team, if it's multiple
                      individuals) *can* prioritize a single backlog that encompasses multiple
                      projects. Can they do it easily? Probably not. Can they be 100% sure
                      that the priority is the best? Probably not. But they can do it and
                      give their best guess as to the business priority order of the backlog
                      stories. They may mix stories from various projects as they best see fit.

                      This, while perhaps not optimal, is workable--and it's greatly preferred
                      to having multiple backlogs for a single team, and pushing the
                      priorities down to the decisions of the technical level. Does the
                      company want the developers deciding which project is most important at
                      the moment? Probably not, but I've seen POs operate in this fashion
                      because it was easier for them than negotiating with the other POs. In
                      other words, rather than make explicit decisions on business value, they
                      used the development team as a tool to compete with other POs.

                      > Based on the assumption you have to work on different projects in
                      > same sprint, my suggestion is :
                      >
                      > You should have your team's capacity estimated, then perhaps you need
                      > to negotiate with project managers about capacity division among
                      > projects. Then use your project specific capacity to select product
                      > backlog items for different projects.

                      I've seen this result in exactly the situation I mention above. As
                      estimates are only estimates, the developers are put in a position of
                      deciding whether to continue working on an unfinished story or switch to
                      something different because they've used up the capacity allotment. Or
                      perhaps they're pressured into working overtime because the POs will
                      blame the developers for anything that goes wrong. A lot of things can
                      happen, but few or none of them are Agile.

                      I can tell you that that it's not pretty, and it's not good for the
                      business.

                      - George

                      --
                      ----------------------------------------------------------------------
                      * George Dinwiddie * http://blog.gdinwiddie.com
                      Software Development http://www.idiacomputing.com
                      Consultant and Coach http://www.agilemaryland.org
                      ----------------------------------------------------------------------
                    • George Dinwiddie
                      ... I ve elaborated further on this at http://blog.gdinwiddie.com/2007/12/03/combined-backlog-for-multiple-projects/ Let me know what you think (either here or
                      Message 10 of 10 , Dec 3, 2007
                      • 0 Attachment
                        George Dinwiddie wrote:
                        > I can tell you that that it's not pretty, and it's not good for the
                        > business.

                        I've elaborated further on this at
                        http://blog.gdinwiddie.com/2007/12/03/combined-backlog-for-multiple-projects/

                        Let me know what you think (either here or there).

                        - George

                        --
                        ----------------------------------------------------------------------
                        * George Dinwiddie * http://blog.gdinwiddie.com
                        Software Development http://www.idiacomputing.com
                        Consultant and Coach http://www.agilemaryland.org
                        ----------------------------------------------------------------------
                      Your message has been successfully submitted and would be delivered to recipients shortly.