プロジェクトが重複しているときにスクラムバーンダウンチャートを計算する方法は？
私のチームには、短期的なプロジェクトと長期的なプロジェクトがあります。チームはこれらのプロジェクトを異なる日に提供する必要があり、これらを提供するための取り組みは、各スプリント中に複数のプロジェクトのストーリーに取り組むチームと並行して実行されます。
バーンダウンを計算しようとすると、どうしたらよいかわかりません。
チームがプロジェクト間で分割されると、人々がプロジェクト全体の専門分野に最も適したタスクにシャッフルするため、速度は週ごとに劇的に変化する可能性があります。これにより、プロジェクトごとに信頼性が高く意味のあるバーンダウンチャートを作成することが困難になります。
ただし、ストーリーを1つのバーンダウンチャートにまとめると、リリース日が異なり、プロジェクトごとにどのポイントが残っているかが明確でない場合に、リリースに対してどのように追跡できますか。
これに対処するための良い方法はありますか？
SCRUMチームが複数のプロジェクトのストーリーに取り組む場合、いくつかのバーンダウンチャートが必要です。
- 現在のスプリント内のストーリーの進捗状況を示す1つのチャート。このチャートは、チームがスプリントの目標に向かってどのように進んでいるかを示すために、チームによって毎日更新されます。チャート上のストーリーがどこから来たのかは、チャートにとって重要ではありません。
- プロジェクトがリリース日に向けてどのように進行しているかを追跡するための、プロジェクトごとに1つのチャート。このチャートは、主にプロジェクトマネージャーがプロジェクトの進捗状況を追跡するためのものであり、そのプロジェクトのストーリーがチームによって提供された場合にのみ更新する必要があります。
速度測定はSCRUMであり、チームがスプリントで処理できる作業/複雑さの量をどの程度一貫して推定しているかを測定することを目的としています。これは、作業単位/複雑さの参照として使用する単一のゴールデンスタンダードがある場合にのみ機能します。
ゴールデンスタンダードはチーム間で異なる可能性があります（そして今後も異なります）が、チームが異なるプロジェクトのストーリーに取り組んでいる場合でも、チーム内で一貫している必要があります。
このような黄金の基準を確立するための推奨される方法は、中程度の努力のストーリーを選び、その3つのストーリーポイントを与えることです。次に、そのゴールデンスタンダードに関連する他のすべてのストーリーを見積もります。
バーンダウンチャートは、リリースに残っている作業量（ポイント）を見積もるために使用されます。場合によっては、これは、配信に基づいてリリース日の大まかな概算を取得するように予測できます。
純粋にストーリーポイント（リリース日ではない）を追跡することが目標である場合、ほとんどのツールでは、マスタープロジェクト内に機能またはサブグループを作成し、各機能のストーリーポイントチャートを個別に取得できます。これは、各機能のストーリーの流れを追跡するのに役立ちます。
ただし、リリース日に対して時間通りの配達を追跡しようとしている場合、ワークフローはそれをやや無意味にします。あなたのチームが特定のプロジェクトのために毎週異なる時間数を費やしていることを考慮してください。将来、毎週どのくらいの労力を費やすことができるかわからない場合、すべてのタスクがいつ終了するかをどのように計算しますか？
そうは言っても、私にはいくつかの提案があります。個々のプロジェクトごとに標準速度を「概算」することができます。チームの優先順位を積極的に変更して、チームが「全体として」プロジェクトごとに標準的な速度を出力するようにします。個人は、特定のプロジェクトでの専門知識に応じて異なります。
とにかくこれを行って、プロジェクトが遅れないようにします。そのプロセスを形式化してから、この速度を使用して時間通りのメトリックを追跡します。
ストーリーポイントは相対的な価値です。この話は他の話と比べてどれくらいの仕事ですか？参照があれば、プロジェクトに関係なく、すべてのストーリーを見積もることができるはずです。 1つのプロジェクトでの同様のタスクは、常に他のプロジェクトよりも多くの作業である可能性がありますが、それでも作業量を参照ポイントと比較できます。
その場合、スプリントごとのストーリーポイントの速度は、チームが担当するプロジェクトではなく、チームに依存する必要があります。
次に、見積もりを行うことができます。Thisプロジェクト1の作業は、プロジェクト1が完全に優先される場合に実行されます。プロジェクト2からこれらのストーリーを取り込むと、これだけのことが完了します。