プロダクト バックログを予測する

Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022 |Azure DevOps Server 2020

Teams は予測ツールを使用して、スプリント計画の取り組みを支援できます。 チームのベロシティの値を差し込むと、予測ツールはバックログのどの項目が将来のスプリント内で完了できるかを示します。 どちらのツールも、バックログ項目を見積もるチームの能力に依存するチーム固有のツールです。 チームがスプリントを 1 つまたは 2 つ完了すると、チームのベロシティを使用して、今後のスプリント内で完了できるバックログの量を予測できます。

予測ツールは、チームが重要な計画の質問に答えるのに役立ちます。

• スプリントのキャパシティ プランニング: 今後のスプリントで完了できるバックログ項目の数はいくつですか?
• リリース計画: バックログ内のすべての項目を完了できるタイミング
• リソース計画: 目標の納期を満たすには、どのような速度が必要ですか?
• スコープ管理: 今後のリリースに優先順位を付ける必要がある機能はどれですか?

この記事では次のことを説明します。

Prerequisites

予測の基礎について

予測ツールに進む前に、Azure Boards での予測のしくみを理解することが重要です。

予測の原則

• 速度ベースの予測: 予測ツールでは、チームの履歴速度を使用して将来の容量を予測します
• スプリントの整合性: 予測では、一貫したスプリントの長さとチーム容量が想定されます
• 作業項目の見積もり: 正確な予測には、一貫した信頼性の高い作業項目の見積もりが必要です
• 状態ベースのフィルター処理: 特定の状態 (提案済み、進行中) の作業項目のみが予測に含まれます

予測の制限事項

• 過去の業績評価指標: 予測は履歴データに基づいており、将来の変化を考慮していない可能性があります
• チームの変更: チーム構成の変更に対して予測が自動的に調整されない
• 外部依存関係: ツールは外部のブロックや依存関係を考慮しません
• 推定精度: 予測品質は作業項目の見積もりの精度によって異なります

必須および推奨されるアクティビティ

チームのバックログの予測を試みる前に必要なものを次に示します。

必要な設定

• イテレーション パス (スプリント) を定義し、チームイテレーションを構成する
  • 予測の精度を高めるためには、スプリントの期間を揃える必要があります。
  • プロダクト バックログ全体を予測するのに十分な将来のスプリントを選択します。
• バックログ項目を定義して見積もります。 チームのバックログから作業する場合、作成した項目は自動的に現在のスプリント (イテレーション) とチームの既定の区分パスに割り当てられます。
• 作業項目の状態の更新: 作業の開始時と完了時にバックログ項目の状態を更新します。 速度グラフに表示されるのは、状態が [ 提案済 み] または [進行中] の状態カテゴリにマップされているバックログ 項目のみです。 (詳細については、「ワークフローの状態と状態カテゴリ」を参照してください。)

推奨プラクティス

• 推定のばらつきを最小限に抑える: バックログ項目を定義してサイズを設定し、見積もりのばらつきを減らします。
• バグ追跡を構成する: チームがバグをどのように扱うかを決定します。 チームがバグを要件のように扱うことを選択した場合、バグはバックログに表示され、ベロシティ チャートと予測内にカウントされます。
• チームのエリア パスを設定する: 予測ツールは、チームの既定の設定に基づいてそれらの項目を予測します。 これらの設定では、項目をチームの既定の区分パスに含めるか、除外するかを指定できます。
• フラット階層を維持する: バックログ項目とバグの階層を作成しないでください。 リーフ ノード (同じカテゴリ階層の最後のノード) の表示は、ボード、スプリント バックログ、およびタスクボードにのみ表示されます。 詳細については、「並べ替えと入れ子の問題を修正する」の「バックログとボードに階層 (入れ子になった) 項目を表示する」を参照してください。
  要件、バグ、タスクを入れ子にするのではなく、フラットなリストを維持し、異なるカテゴリ項目間に深さが 1 レベルの親子リンクのみを作成します。 要件またはユーザー ストーリーをグループ化するには、フィーチャーを使います。 ストーリーをフィーチャーにすばやくマップできます。 マップによって、バックグラウンドで親子リンクが作成されます。
• スプリントのクリーンアップを完了する: スプリントの終了時に、チームが完了したバックログ項目の状態を更新します。 不完全な項目を製品バックログに戻し、将来のスプリント計画会議で検討します。

チームのセットアップに関する考慮事項

今後のスプリントを予測する

予測ツールを使って、スプリント内で完了できる項目の数を把握します。 ベロシティを設定することにより、チームがアクティブにしたスプリントのセット内でスコープに含まれる項目を確認できます。

製品のバックログを予測するには、次のアクションを実行します。

1. 「Boards>Backlogs」を選択し、チームセレクトメニューから適切なチームを選びます。

   

   別のバックログを選ぶには、セレクターを開いてから、別のチームを選ぶか、[バックログ ディレクトリの表示] オプションを選びます。 または、検索ボックスにキーワードを入力して、プロジェクトのチーム バックログの一覧をフィルター処理します。

   

2. バックログ レベルとして [ストーリー] (アジャイルの場合)、[問題] (Basic の場合)、[バックログ項目] (スクラムの場合)、または [要件] (CMMI の場合) を選んだことを確認します。

   

3. (省略可能) 表示する列とその順序を選ぶには、 アクション アイコンを選んで、[列のオプション] を選びます。 詳しくは、 列オプションを変更するをご参照ください。

   

4. 表示オプション アイコンを選び、[予測] を [オン] にスライドします。 作業を簡単にするには、[マッピング] と [計画] ペインを [オフ] にします。

   

   [進行中アイテム] を [オフ] に設定すると、予測にカウントされないアイテムが非表示になります。 スクラムで "コミット済み" または "完了" に設定されている項目と、アジャイルおよび CMMI で "アクティブ"、"解決済み"、または "完了済み" に設定されている項目は、予測ツールで無視されます。

5. チームの予測ベロシティを入力します。

   

   Tip

   チームが複数のスプリントを作業してきた場合は、ベロシティ ウィジェットからチームのベロシティを把握できます。 最も正確な予測を行うには、過去 3 ~ 6 回のスプリントの平均速度を使用します。

   ツールでは、チームによって選択された将来のスプリントごとに線が描画されます。 予測線は、今後のスプリントでチームが完了できる作業量を示します。 通常、最初の線より上にある項目は、現在のスプリントで既に進行中です。 1 番目と 2 番目の予測線の間にある項目は、示されているスプリントで完了できるものを示します。

予測結果について

予測を視覚化したデータの読み取り

予測ツールには、スプリントの容量を理解するのに役立つ視覚的なインジケーターが表示されたバックログが表示されます。

• 予測線: 作業項目をスプリント バケットに分割する水平線
• スプリント ラベル: 各行にはスプリント名と容量でラベルが付けられます
• 速度の引き継ぎ: あるスプリントからの未使用の速度が次のスプリントに進みます。
• 項目の配置: ライン間の作業項目は、そのスプリントで完了できる内容を表します

予測データの解釈

予測結果を確認するときは、次の要因を考慮してください。

• 手動検証: 結果を手動で確認して、予想される内容と予測ツールに表示される内容の不一致を把握します。
• スプリント容量: スプリントごとに予測される作業量 (作業量、ストーリー ポイント、またはサイズ) を確認します。
• 大きな作業項目: 項目の作業量がチームの速度に近い、またはそれより大きい質問予測結果。
• 速度の引き継ぎ: 以前のスプリントの未使用の容量が将来の予測にどのように影響するかを理解します。

予測解釈の例

この例で使われているベロシティは 20 です。 予測ツールでは、予測ライン間に表示される項目の数が、スプリント内で完了できる項目、または前のスプリントの未使用のベロシティ ポイントを使用できる項目に制限されます。

予測ツールは、各ユーザー ストーリーまたはバグに割り当てられたストーリー ポイントの数に基づいて、イテレーション 2 から 6 の間に 2 ~ 4 個の項目を操作できることを示しています。 予測ロジックは、あるスプリントから次のスプリントにベロシティ ポイントを持ち越します。

• イテレーション2: 13ストーリーポイントで、アイテム1と2を完了できます。7ベロシティポイントは次のスプリントに繰り越されます。

• イテレーション3: 24ストーリーポイント。アイテム3〜5を完了できます。3 (＝20＋7－24) のベロシティポイントが次のスプリントに持ち越されます。

• イテレーション 4: 21 ストーリー ポイント、項目6から8を完了することができました。2 (=20+3-21) ベロシティポイントが次のスプリントに引き継がれる

• イテレーション 5: 16 ストーリーポイント、項目 9 から 12 を完了することができる。6 (=20+2-16) ベロシティポイントが次のスプリントに引き継がれます。

• イテレーション 6: 23 ストーリー ポイント、項目 13 から 16 を完了できます。3 (=20+6-23) 速度ポイントが次のスプリントに引き継がれます。

  

高度な予測シナリオ

シナリオ 1: タイムラインに必要な速度を決定する

予測ツールを使うもう 1 つの方法は、特定のスプリント セット内ですべてのバックログ項目が完了するまで、異なるベロシティ値を入力することです。 この予測では、項目のバックログを完了するために必要なベロシティの見積もりが提供されます。

その後、現在のチームのベロシティと必要なベロシティの間の差異を評価できます。 この差異は、要求されている時間内に生産の需要を満たすために必要な他のリソースを決めるのに役立ちます。

速度要件分析の手順

1. バックログの合計作業量をカウントする: すべてのバックログ 項目の作業量の見積もりを合計します
2. 使用可能なスプリントの数: 目標日までのスプリント数を決定する
3. 必要な速度を計算する: 利用可能なスプリントで合計作業量を除算する
4. 現在の速度との比較: 電流と必要な速度のギャップを特定する
5. それに応じて計画する: より多くのチーム メンバー、スコープの縮小、またはタイムラインの調整が必要かどうかを判断する

シナリオ 2: 複数のチームを使用したリリース計画

複数のチームが共通リリースに向けて取り組んでいる組織の場合:

1. チーム予測の集計: すべての貢献チームの予測を組み合わせる
2. 依存関係の識別: 配信に影響する可能性があるチーム間の依存関係をマップする
3. 統合ポイントの計画: チーム配信間の統合アクティビティをスケジュールする
4. 進行状況の監視: 予測された配信日に対して実際の進行状況を追跡する

シナリオ 3: チーム サイズの変更によるキャパシティ プランニング

プロジェクト中にチーム構成が変更されたとき:

1. 速度を比例的に調整する: チーム サイズの変更に基づいて速度を増減する
2. 立ち上がり時間を考慮する:新しいチーム メンバーは、通常、完全な生産性を達成するために時間が必要です
3. 実際のパフォーマンスを監視する: 実際の速度と調整された予測を比較する
4. 定期的な再調整: 新しい速度パターンに基づいて予測を更新する

正確な予測のためのベスト プラクティス

見積もりのプラクティス

• 一貫した見積もりスケールを使用する: すべてのチーム メンバーが同じ見積もり基準を理解して適用することを確認する
• 共同で見積もる: チーム コンセンサスに対して計画ポーカーまたは同様の手法を使用する
• 大きなアイテムを分割する: 大きな作業項目をより小さく、より予測可能な部分に分割する
• すべての作業を含める: 容量に影響を与えるバグ、技術的負債、およびその他の作業を考慮する

速度管理

• 実際の速度を追跡する:時間の経過に伴う実際の速度を監視し、それに応じて予測を調整する
• ローリング平均を使用: 安定性のために過去3〜6回のスプリントの平均に基づいて予測を行う
• チームの変更を考慮する: チームの構成が変更されたときに速度の期待値を調整する
• 外部要因を考慮する: 休日、トレーニング、その他の容量への影響を考慮する

予測メンテナンス

• 定期的に更新: スプリントごとに少なくとも 1 回予測を更新する
• 前提条件の確認: 基になる前提条件が有効なままであることを検証する
• 変更を伝える: 予測の更新とその影響について関係者に通知する
• 実績から学ぶ: 予測予測と実際の結果を比較して精度を向上させる

予測に関する一般的な問題のトラブルシューティング

問題: 不正確な予測

考えられる原因:

• 一貫性のない作業項目の見積もり
• スプリントの数が少なすぎる場合の速度計算
• チーム構成の大幅な変更
• 外部の依存関係が考慮されない

ソリューション:

• 見積もりプラクティスの確認と標準化
• より長い速度履歴を計算に使用する
• チームの変更の速度を調整する
• スプリント計画に依存関係管理を含める

問題: 予測ツールに予想される結果が表示されない

考えられる原因:

• 間違った状態カテゴリの作業項目
• チーム領域のパスの構成が正しくありません
• スプリント構成の問題
• 作業項目の見積もりがない

ソリューション:

• 作業項目の状態が正しいカテゴリにマップされていることを確認する
• エリア パスとイテレーションのチーム設定を確認する
• スプリントが正しく構成され、割り当てられていることを確認する
• すべてのバックログ 項目に見積もりを追加する

問題: 予測と実績値の大きな差異

考えられる原因:

• 予測できない作業項目のサイズ
• スプリント中のスコープ・クリープ
• 見積もりでは考慮されない技術的な課題
• 容量に影響を与える外部の中断

ソリューション:

• 作業項目の分解を改善する
• より強力なスコープ管理を実装する
• リスク バッファーを見積もりに含める
• 割り込みによる作業を追跡して管理する

次のステップ

関連コンテンツ

• チームの進捗速度
• イテレーション パス (スプリント) の定義とチーム イテレーションの構成
• タスクボードを使ってスプリント中の作業を追跡する
• スプリント バーンダウン チャートを監視して、チームが順調にスプリント計画を完了できるかどうかを判断する
• Azure Boards の構成とカスタマイズ
• アジャイル プロセスのガイダンス