マルチプロジェクトマルチチームスクラム
異なる地理的位置にある2つのチーム（AおよびB）がプロジェクトPを開発しています。
どちらのチームも他のいくつかの小さなプロジェクトを開発しています。AにはプロジェクトPA1とPA2があります。 BにはPB1とPB2があります。 Pは2つのチームに共通する唯一のものです。
今日のスクラム設計：
- 各チームにはPOがあり、優先順位を一緒に決定します。
- プロジェクトPおよびPA1とPA2のストーリーを含む1つの一般的なバックログ。 PB1とPB2はオフスクラムで行われます。
- 各チームには独自のスプリントとSMがあります。チームAは、プロジェクトP、PA1、およびPA2に関連するバックログからストーリーを選択します。チームBは、Pに関連するストーリーのみを取り上げます。
問題：
- PB1とPB2もスクラムで管理したい。
可能な解決策：
- PB1とPB2を同じバックログに追加しますか？ -これまで以上にバックログを複雑にします。
- 3つのバックログ（P、PA1-2、PB1-2）に分けますか？ -「チームごとに1つのバックログ」というルールがあります...それを破る必要がありますか？ TFSでもサポートされていますか？
問題を解決する方法はありますか？
私は現在、3分の2の段階にあります アジャイルソフトウェア要件：チーム、プログラム、およびエンタープライズのリーン要件の実践 そして、この本は、関連する多くのトピックをカバーしているので、この本を強くお勧めしますアジャイルプロセスを複数のチームにスケールアウトし、エンタープライズレベルの製品（つまり、何年にもわたる製品）のバックログを維持する
私はあなたの特定の状況に遭遇していないので、実際の私のアドバイスが実際にどのように機能するかは言えませんが、アジャイルでの自分の経験と外部の読書との組み合わせに基づいて、これは私が提案するものです：
- 製品ごとに個別のバックログを保持します。したがって、P、A1、A2、B1、B2の5つのバックログがあります。このように、各バックログは、あなたがその製品の開発のどこにいるのか、そしてその製品の何が待ち受けているのかを明確に示します。
- バックログにストーリーが多すぎると、管理する必要がある項目が増えるため、全体的な俊敏性が低下します。 1つのバックログに5つの異なる製品があると、あまり生産的ではありません。特に、複数の製品所有者がいる場合。バックログが1つだけあり、突然CTOがやって来て、A2が最優先事項であり、他のすべてを保留にした場合、どのくらい移動する必要がありますか？
- 製品のバックログをやや高レベルのままにします（つまり、1〜3 ptに分解しないでください）。大きいアイテムのみを使用すると、ストーリーの数が減少し、チームが対処する必要があり、作業の優先順位付けがはるかに容易になります。
- AとBの2つのチームバックログを作成します。ビジネスニーズと優先順位に基づいて、P、A1、A2からストーリーを引き出してAに転送できます。P、B1、B2はBに転送されます。
- 理想的には、チームバックログに数回のイテレーションに相当するストーリーのみが含まれることになります。このようにして、ビジネスニーズと優先順位が変化すると、各製品のバックログから取得するストーリーの量を調整できるようになります。
- これらのチームのバックログは製品のストーリーを取り、詳細を定義した細かいチャンクに分解する可能性があります。ただし、詳細を記入するのは、チームが実際に作業を行う準備ができているときだけです。
ポジティブなことは、別々の製品バックログがあることは5つの速度があり、それらの製品の各機能がいつ配信されるかを正確に予測できることを意味します。
5つのプロジェクトと2つのチームでポイントスケールを標準化することが課題になります。これは、異なる製品/チームが異なるポイントスケールを使用する場合、速度には価値がないためです。上記の本は、この標準化の方法のいくつかについて述べています。基本的には、同じ基本重量から始めたいとします（例：1pt〜1日の作業）。また、スクラムのスクラム会議（おそらくテクニカルリードがいる）を行うことは、より高いレベルの計画に役立ち、チーム間のポイントスケールと作業の調整を均等化します。
ストーリーのポイントについてのアドバイスの一言---私は一般に、生のポイントを外部の当事者と共有したくない。チームAとチームB（特に同じ場所に配置されておらず、互いに会話している場合）は、独自の相対ポイントを持ち、各ユーザーストーリーの独自のベースラインと努力のレベルを測定できるようにする必要があります。チームAがスプリントあたり50の速度を持つことができ、チームBが25の速度を持つことができる理由について、利害関係者と製品所有者の間であまりにも多くの議論がありました。私は透明性のために全員ですが、そのような議論からのチームメンバー。外部から何かを報告する必要がある場合は、「1-3（小）5-13（中）20-40（大）100+（XL）」のような点からTシャツのサイズを翻訳します。これは、スクラムやストーリーポイントと相対的な見積もりの概念に精通していない、強力で独断的な関係者がいる場合に特に重要です。あなたの最善の策は、バックログの優先順位、一般的なリリース計画、そしてポイントを示さず、日付のトレンドラインのみを示すバックログバーンダウンチャートを彼らに見せるだけです。これらのポイントは、何よりもまず、努力のレベルについてチームメンバー間で議論を引き出すためにあります。それが行われた後、それはより良い計画を立てるために製品所有者またはスクラムマスターとしてあなたを助けるかもしれません。チームの有効性やハードワークを判断するために、利害関係者が客観的なスコアになることは決してありません。そうすることは彼らが正直であることを思いとどまらせるでしょう。