It's not uncommon for an organization to have one group of developers who need to complete multiple projects. In those situations, how should the group be structured, and how should their work be planned and allocated?
When the ratio of developers to projects is relatively high (say, 6-10 developers per project), and the size of the projects and their relative priorities is known, this is commonly addressed by splitting the developers into two or more teams.
On the other hand, if the ratio of developers per project is quite low (1-3 developers per project), and the size of the projects and their relative priorities is less clear or subject to change, it can be difficult to split the developers into teams in a meaningful way.
Gilad Gruber asked for some advice on how to structure a project and team:
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.
Wolfgang Shulze Zachau shared his experience:
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 [Product Owner (PO)] is left to make his own decisions.
He added, "Of course, you need the right kind of guy to be PO."
Xu Yi-Kaveri disagreed:
I [am] 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.
He raised the concern of how you can prioritize amongst multiple projects, and confusing feature priority and project priority. Instead, he suggested:
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.
Roy Morien suggested choosing between the approaches using common sense:
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.
Finally, George Dinwiddie stepped in to share (via mailing list and blog) some of the problems he has experienced with using multiple product backlogs:
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.