組織において一つのデベロッパグループが複数のプロジェクトを完成しなければならない事は珍しいことではない。このような状況においてグループはどのように構成され、またどのように彼らの作業をどのように計画し、配分するべきなのだろうか。
プロジェクトに対するデベロッパの率は比較的高く（一つのプロジェクトにおいて6から10人とする）、そしてプロジェクトと相対的な優先事項のサイズが分かっている際に、通常これはデベロッパたちを二つかそれ以上のグループに分割することによって提示される。
一方、一つのプロジェクトに対するデベロッパの率が低く（プロジェクトごとに1～3人）、プロジェクトのサイズと相対的な優先事項が明確でなく、変更する可能性がある際にはデベロッパたちを効率的にチーム分配するのは困難かもしれない。
Gilad Gruber氏はプロジェクトとチームの構成に関するアドバイスに答えた(source)。
私はこれに対応する最善の方法とSCRUMの手法が何であるか考えていました。私としては最善の方法はチームごとにシングルバックログを設けることです（たとえチームが複数のプロジェクトに属するアイテムのバックログに取り掛かっていたとしても）。純粋主義者はチームを分配して複数のバックログを持つことを勧めるでしょう。
Wolfgang Shuze Zachau氏は彼の経験を下記のように解説している(source)。
私達は多様なプロジェクトを補っている一つの製品バックログを持っています。一人の製品オーナーがいて彼が顧客と他のステークホルダーとの綿密なコンサル テーションの後最終的な優先事項を決定するのです。それは製品オーナーが独自の判断で彼自身の決断を下す事ができる限り効果的な方法です。
そして彼は”もちろん製品オーナーにふさわしい人を選ぶ必要がありますよ。”と付け加えた。
Xu Yi-Kaveri氏はこの意見に同意していない(source)。
私はそれぞれのチームにシングルバックログを持つというアイディアに反対します。まずはじめに製品オーナーは製品バックログのフォーマットを決定できる人物です。そして基本的に異なる複数のプロジェクトに一人のプロダクトオーナーはいないですからね。
また彼は複数のプロジェクトの中でどのように優先順位を決めるか、そして機能とプロジェクトの優先順位化における混乱という懸念を持ち出した。
チームのキャパシティは事前に知っておくべきで、多分プロジェクト内においてキャパシティ部門に関してプロジェクトマネジャーと交渉する必要があるかもしれません。そして異なるプロジェクト用に製品バックログアイテムを選択するため、プロジェクトに特化したキャパシティを使用するのです。
Roy Morien氏は常識を使って(source)アプローチを選択することを提案している。
これらの全てにおいて常識が優先されるべきなのです。それぞれにPBがいるたくさんのチームを持つことが便利で効果的であるのなら、それはそれでいいと思い ます。それぞれのPBは別々に優先化されてなければいません。もしも共通のバックログがたくさんのチームに共有されているのであれば、それは同じPBを共有している適切な人数（7人から最大で9人）のチームでPBの優先化を処理し、たくさんのSprintバックログを始めるアイテムを順序良く選択するということを意味しているのです。
最後にGeorge Deinwiddie氏は複数の製品バックログを使用して経験した問題について語ってくれた（メーリングリストとブログで）。
予測は予測に過ぎないので、デベロッパ達は未完結の話に引き続き取り掛かるべきなのか、それともキャパシティの割り当てを全て使ってしまったから違うものに置き換えるのかどうかを決定するという状況に置かれるのです。それかもしくはなにか事が誤った方向に向かったら、製品オーナーがむやみにデベロッパ達を責めるので大変な残業を強いられているかもしれません。起こり得る事はたくさんありますがそれらはAgileではないのです。
それは奇麗事ではなくビジネスのためにもよくないと言う事だけは確実です。
原文はこちらです：http://www.infoq.com/news/2007/12/multiple-projects-one-agile-team