事業上一応複数に分割されるプロジェクトを、開発チームの規模的に一つのチームで回していくという場面にこの先遭遇しそうなので、 そのあたりが、スクラムやアジャイル開発コミュニティによってどのように取りあつかわれているのかを調査しています。
資料
Scrum.orgでの議論
スクラム開発においては、「プロジェクトで何のタスクをこなすか」という観点ではなく、 ユーザーにたいしてどのような価値提供をこのスプリントで達成するのかという観点でスプリントゴールを切っていく事になるので、
もしユーザーに対して提供する価値という観点から一人の意思決定者(PO)が優先度をつけられるような関係性にあるプロジェクトならば 単一のバックログにして取りくむ事ができるはず。その場合は通常のスクラムと同じスプリントイベントを実施していく事ができる。
逆に、それぞれが独立しているような複数POのプロジェクトの場合は、例えば週次でプロジェクトをスイッチするなど、 スプリントのサイクル毎の目標はチーム内で一つにしておいて回すべきだろうという話。
The Agile Directorの記事
こちらの記事では、基本的に複数プロジェクトを書けもちするのは非推奨とい立場で、 仮にメインプロジェクトと、メンテナンス系のプロジェクトというような種類ならば兼務も可能かもしれないというスタンス。 その場合、メンテナンスのタスクの固定バッファを枠として持ち、 バグフィックスなどはスプリントのサイクルをまたずにすばやくリリースができるようにカンバン方式でCDしていけると良いのではという話
PjM視点でのMedium
PjM観点で個別のタスクを誰に割りあてるか、その優先度はという形式でつけていくのはプロジェクトの優先度の変動が多い環境では困難であり、 個々のメンバーの能力に依存したタスク配分になってしまうため、メンバーの急な病欠などにも対応できなくなるという観点で、
PjMは、プロジェクト粒度での優先度のみを管理し、プロジェクト内の各タスクについては チームのメンバーが手が開きしだい取っていくというカンバン方式にちかい方針。
Quoraでの質問
基本的に非推奨であるものの、やるしかない場合には適切に単一のバックログとしてまとめあげてベロシティを計測し スクラムイベントや、バーンアップチャートなどを通して、ステークホルダー(複数いる場合は)にそれぞれのスプリントで 各プロジェクトのタスクをどれくらいやるのかを話しあわせる。
まとめ
共通した切り口として、バックログを一つにまとめる事でチームが一つの目標に集中できるようにするという観点があります。 Scrum.orgの議論でも、どうしてもまとめられない時は週次でプロジェクトを切りかえるなど、スプリント中にチームが気にするバックログは 単一のものにしておく事が重要そうです。
他の会社さんを見ていてもそうですが、基本的にあまり複数プロジェクトを回すという形式になるのはやはり非推奨なようです。
うちではこうやってるよとか、こういう所に気をつけた方が良いなどがありましたら、コメント等でご意見いただけますと幸いです。