スプリント全体計画

プロジェクト全体のスプリント計画を立てます。

  1. 1スプリントの長さのタイムボックスを作ります。
    • 1スプリント2週間を基本とします。成熟していないスクラムチームの場合には1週間にしてください。
    • 祝休日が間に挟まる場合、最低でも8営業日は確保するように調整します。
    • スプリントの開始曜日は固定した方が、リズムが生まれるので好ましいです。
    • スプリントの開始曜日は、下記観点から月曜日は避けてください。
      • 土日をはさみウォームアップに時間がかかる。
      • 日本はハッピーマンデーがあるので、曜日固定が崩れやすい。
  2. プロダクトバックログを作ります。
  3. 機能要求をもとにストーリーをあげます。
    • ストーリーは体言止めにはせず、「～できるようにする」とか「～を組み込む」のように書くと一覧の視認性は落ちますが、頭に入ってきやすくなるのでオススメです。
    • １スプリント内で完結できないような、粒度の大きいストーリーはストーリー分割チートシートを参考に分割します。
  4. ストーリーの概算ストーリーポイントを見積もります。
    • ストーリーは十分に分割して、自分たちが扱える(少なくとも1スプリントに収まる)サイズになるようにしてください。
    • 開発チームによって変わりますが、次にあげるように、ストーリーを分割するべきか判断する基準を設けることも役に立ちます。
      • 1つのストーリーが13ポイントより大きくなりそうな場合は、ストーリーを分割する。
      • 1つのストーリーに2～3日よりもかかりそうな場合は、ストーリーを分割する。
  5. ストーリーの依存関係を考慮し、優先順位を決めその順に並び替えます。
  6. 機能要求にもとづいたストーリーに含めていないテストは、別途ストーリーとしてあげます。
    • ここでは、プロジェクト全体のうち、作成するスプリント全体計画が対象とする工程で計画されているテストのみあげればよいです。
  7. スプリントバックログを作ります。
  8. 開発チームのベロシティ(1スプリントで何ストーリーポイント消化するか)を決めます。
    • 開発チームが未成熟(初めて組むメンバー)の場合は、初期スプリントではベロシティが低く、徐々にベロシティが向上することが予想されるので、それを考慮してスプリント毎のベロシティを決めてください。
  9. スプリント毎のベロシティに収まるように、プロダクトバックログからスプリントバックログに移していきます。
  10. マスタスケジュールとの整合性を確認します。
  • 受託開発においては、次のようなイベントがマイルストーンとして置かれています。
    • 社内のスクラムチーム外の人によるレビュー
    • お客様レビュー
    • 他チームとの成果物の授受
    • 他システムとの接続テスト
  • それらの1スプリント以上前に、必要なストーリーが完了しているようになっていることを確認します。
    • マスタスケジュールに決められたマイルストーンからセーフティーリードを保って、開発をすすめることが成功の鍵です。
    • セーフティーリードが取れない場合は、始めるのが遅かったか、実現不可能なスケジュールかのどちらかです。

実際のプロジェクトで作成した計画の例

受託開発での注意点

Note: ウォーターフォール開発では、プロジェクト計画書という形でプロジェクトを計画するのが一般的です。このドキュメントに記載しているようにスプリントを計画するからといって、それらに記載している内容がすべて不要になるわけではありません。 スプリント全体計画は、プロジェクト計画のうち「開発スケジュール」の計画にあたると考えてください。

プロジェクト全体がウォーターフォール型で、一部だけをスプリントで運営する場合、計画の際に注意が必要になります。ただ、基本的にはウォーターフォール型でスケジュールを作成する際に注意する点とあまり変わりません。

次にあげるような点を考慮せずにスケジュール化してしまうと、見積り通りに完了しなかった、というだけで上位層への報告や再計画が必要になってしまい、リスケの繰り返しという悪循環に陥ってしまうリスクが大きくなります。

  1. 計画に基づいて状況を判断するため、「計画通り」に進捗することが重要
    • 開始当初から終了時点まで、一定のベロシティになることを期待しないでください。開始直後はベロシティが低くなる傾向が強いです。
      • ベロシティが上がるのは、主に「運営方法に慣れるから」ではなく、「要件や設計に対する理解が深まるから」であったり「開発技術に慣れるから」であることが多いです。
      • 開発チームのメンバーの知識・スキルと、プロジェクトで必要となる知識・技術のギャップが、ベロシティが向上する幅の目安になると思います。
        • このギャップを埋めるために手を打つことが、ベロシティの向上につながります。
  1. 「期間・スコープ」が固定されている場合（例えば、一括請負契約の場合など）は、「期間・スコープ・コスト」のうち、「コスト」をコントロールしてプロジェクトを完遂するという考え方が必要
    • マスタスケジュールとの整合性を確認する際に、工程の最後にバッファがとれていることを確認する。
      • 実際にプロジェクトで採用しているバッファの割合は、20%～100%まで様々です。
      • ウォーターフォール型で計画する際と同様に、プロジェクトの特性を踏まえてバッファ量を決めてください。