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?