イテレーションの計画

イテレーション計画ミーティングの目的は、最上位にランク付けされた製品バックログ アイテムのセットの完了にチームがコミットすることです。このコミットメントでは、イテレーションのバックログが定義されます。コミットメントはチームのベロシティまたはキャパシティと、イテレーション タイムボックスの長さに基づきます。

関係者

イテレーション計画は、以下のロールが関与する連携作業です。

  • スクラム マスタ: ミーティングを進行します
  • プロダクト オーナー: 製品バックログ アイテムとその承認基準の詳細を示します
  • デリバリ チーム: コミットメントの達成に必要なタスクと工数を定義します

バックログ

計画ミーティングの前に

始める前に、以下のことを確認してください。

  • 製品バックログのアイテムがチームによってサイジングされて、ストーリー ポイントの相対値が割り当てられている
  • 製品バックログは、製品所有者の優先順位を反映するようにランク付けされたスタックである
  • ランク付けされたこれらのバックログ アイテムの承認基準の一般的な知識がある

機会均等バックログ

製品バックログは、新機能、および既存の機能の修正に対応します。製品バックログ アイテムがスケジュールされている順序は、その起源とは完全に無関係です。

イテレーション計画のための、製品バックログ アイテムの重要な特性は以下のとおりです。

  • イテレーション内で完了できるほど小さい
  • 正しく実施されたことを確認できる

適切なサイズのバックログ アイテム

イテレーション内で完了するには大きすぎる製品バックログ アイテムは、小さく分割される必要があります。製品バックログ アイテムをプロセスではなく値で分割するのが最善の方法です。

子によって価値が実現されるように製品バックログ アイテムを分類できれば、イテレーションによって価値が漸進的に実現されます。プロセスで分割すると、すべての子が完了するまで価値が実現されないので、市場投入までの時間に影響が及びます。

複合ストーリーは分割で簡単に分けることができます。複雑なストーリーには別の難しさがあります。ビル ウェイク氏が http://xp123.com/xplor/xp0512/index.shtml で 20 通りの方法を挙げています。

計画プロセス

イテレーションの内容の計画には 2 つの段階があります。イテレーションに適合するユーザ ストーリーの数を決定してから、それらのストーリーをタスクに分割して所有者に割り当てます。

サイジングは、ユーザ ストーリーの相対的なスコープを表し、通常では相対的なポイントで実行されます。ユーザ ストーリーの初期作成時、バックログの改善セッション中、および計画ミーティングの前に、チームは定期的にユーザ ストーリーのサイズを見積もります。チームは計画を開始するときまでに、バックログの先頭付近にあるどのストーリーがイテレーションに適合するのかを把握しておく必要があります。

見積もりは、ユーザ ストーリーからタスクへのブレークダウンを表します。ユーザ ストーリーの実現に必要な細かい手順が特定されたら、各タスクには時間単位の見積もりが設定されます。タスクが完了までにどれだけ近づいているのかをチームはこの数値から知ることができます。チームは、個人への負荷が過剰にならないように、各チーム メンバがイテレーションで作業できるタスク時間数(キャパシティと呼ばれる)も把握します。

ユーザ ストーリー ポイントからタスク合計時間への変換や、ユーザ ストーリー ポイントとタスク合計時間の比較は行わないでください。

ユーザ ストーリーのサイズ

成熟したチームは、過去のベロシティを使用して、イテレーション中にコミットする製品バックログ アイテムを決定します。ベロシティとは、チームがイテレーション内で完了可能なユーザ ストーリー ポイントの平均数です。たとえば、新しいチームが最後の 3 つのイテレーションで 12、14、および 8 のポイントを完了しました。最近のイテレーションでは技術的な問題が発生して解決されましたが、そのことが原因で完了できたストーリー ポイントは 8 つだけであったことがレビュー ミーティングで判明しました。チームはこれらの要因に基づいて、次のイテレーションで使用するベロシティを 12 ストーリー ポイントと見積もります。

CA Agile Central でイテレーションを作成するときには、チームが完了できると見込んでいるユーザ ストーリー ポイント(またはその他の値)を[計画されたベロシティ]フィールドに入力してください。チームが新しいと、ベロシティが不明である可能性があります。イテレーション計画の基礎データとして使用できるほどベロシティが安定していないこともあります。新しいチームは、過去のプロジェクト作業に基づいた最も有力な予測値を使用してコミットしてください。スケジュールされたすべての作業が早く完了したら、チームは作業をさらにプルすることができます。ベロシティの見積もりが低すぎる場合は、チームは次のイテレーションでコミットする作業を減らす必要があります。

タスク キャパシティ

チームのキャパシティは、各チーム メンバの 3 つの単純な値から計算されます。

  • 作業日の理想的な時間数
  • メンバがイテレーション期間中に作業できる日数
  • メンバがこのチームだけに専念する時間の割合

たとえば、5 人のメンバで構成されているチームについて考えてみます。メンバは全員フルタイムでチームにコミットしています。各メンバが行うタスク作業は 1 日あたり約 6 時間であり、誰も休暇を取りません。イテレーションが 1 週間である場合の計算は次のようになります。

チームメンバ 5 人 X 理想的な時間 6 時間 X 作業日 5 日間 = タスク キャパシティ 150 時間

計画の手順

  1. プロダクト オーナーは、最上位にランク付けされたバックログ アイテムについて説明します。
  2. チームでは、各製品バックログ アイテムを完了するのに必要なタスクを決定します。
  3. チーム メンバがタスクを引き受けることを申し出ます。
  4. タスク所有者は、各タスクを完了するために必要な、理想的な時間数を見積もります。
  5. 計画の手順を繰り返し行うと、チームは最適なベロシティを超過せずにデリバリにコミットできます。

イテレーション計画中にいずれかのメンバがキャパシティを超えた場合は、チームは協力して負荷を分散します。

議題

  1. 開始
    参加者を迎えて、目的、議題、および整理ツールを確認します。
  2. 製品ビジョンとロードマップ
    チームに概要を再び説明します。
  3. 開発ステータス、アーキテクチャの状態、前のイテレーションの結果
    計画に影響を及ぼす可能性がある新情報について話し合います。
  4. イテレーションの名前とテーマ
    名前とテーマを話し合って決定します。
  5. 以前のイテレーションのベロシティ
    このイテレーションに使用するベロシティを指定します。
  6. イテレーションのタイムボックス(日付、作業日数)
    タイムボックスと総作業日数を決定します。休日、またはチーム全体に影響を及ぼすその他のイベント日を減算します。
  7. チームのキャパシティ(対応可能度)
    各チーム メンバは、個人の対応可能度に基づくキャパシティ、このプロジェクトやその他のプロジェクトへの割り当て、このイテレーションでの毎日のタスク作業時間を計算します。
  8. 問題と懸念
    現在認識されている問題と懸念事項を確認し、必要に応じて記録します。
  9. 完了の定義の見直しと更新
    前回のイテレーションからのテクノロジ、スキル、またはチーム メンバ構成の変更に基づいて、完了の定義を見直して適切に更新します。
  10. 製品バックログの検討対象ストーリーまたはアイテム
    イテレーション バックログの検討対象として提案された製品バックログ アイテムを提示します。
  11. タスク アウト
    デリバリ チームはタスクを決定し、作業をサインアップし、タスクを見積もります。プロダクト オーナーは質問に答えて、必要に応じて承諾基準を詳しく説明します。スクラム マスタは連携を促進します。
    a. タスク、b. 見積もり、c. 所有者
  12. 新しい問題と懸念
    タスク アウトに基づいて新しい問題と懸念を確認し、必要に応じて記録します。
  13. 依存関係と前提
    計画中に決定された依存関係または前提を確認し、必要に応じて記録します。
  14. コミット
    スクラム マスタが計画への意見をフィスト オブ ファイブで求めます。アジャイル チームおよびプロダクト オーナーは、毎日、現在自分が知っていることに基づいて、これが作成しうる最良の計画であるかどうかについて意見を示し、計画の次のレベルへの移動にコミットします。
  15. 通信と物流の計画
    このイテレーションの通信と物流の計画を確認および更新します。
  16. パーキング ロット
    パーキング ロットの処理 - すべてのアイテムを解決済みに定義、またはアクション アイテムに転換する必要があります。
  17. アクション アイテム/計画
    アクション計画の処理 - 所有者にアクション アイテムを分配します。
  18. ミーティングの振り返り
    これらのミーティングを全員にとって役立つものにするため、ミーティング自体についてのフィードバックを求めます。
  19. 閉会
    計画ミーティングが成功したことを称えましょう。

 

関連トピック

詳細については、Agile ビデオ チュートリアルの「イテレーションまたはスプリントでの作業」を参照してください。

 

フィードバック

ヘルプをお求めですか?CA Agile Central コミュニティは、セルフサービスとサポートのワンストップ ショップです。CA Agile Central サポートにフィードバックを送信したり、答を見つけたり、他のユーザとのコラボレーションには CA Agile Central コミュニティ にご参加ください。