---

スクラムのリリース計画とは？意外な発見があるかもしれません！

リリース計画のゴールは、複数のスプリントの大まかな計画を見えるようにすることです。この例では、通常、三～十二スプリントを扱います。スプリントはタイムボックスで、インクリメントは利用可能な成果です。一回のスプリントで、複数のインクリメントを作ることもできます。

リリース計画は、チームへの次の期待を示す指針になります。

• どの機能を実装するか。
• どの順序で、いつ実装するか。

プロジェクトの進捗を把握し、管理する基準にもなります。本番のITシステムへ実際に配備する目標として、二つの形があります。

• プロジェクト完了前に顧客へ事業価値を届ける、「節目ごとの提供」。プロダクトオーナー、顧客、事業の関係者が合意した、顧客要求の一部を含みます。
• 顧客と事業の関係者の、把握しているすべての要求と機能の希望を含む、最終的な提供。

リリース計画の前に、次の作成物と情報を考慮します。

• 優先順位と見積もりのあるプロダクトバックログ。
• 実測したベロシティ 。チームを作ったばかりなら、過去の類似プロジェクトから推定するか、外挿する必要があります。
• 顧客が定める成功の基準 。日程、範囲、予算内で利用できる人員などです。

リリース計画は、プロダクトバックログと強く結び付くため、プロダクトオーナーが管理し、維持します。

顧客の要求と優先事項に応じて、次の三つのゴールのいずれかを満たす計画を作ります。

• 機能に基づくリリース計画
• 日付に基づくリリース計画
• 機能と日付に基づくリリース計画 （最も一般的）

機能に基づくリリース計画

分かっていること： チームのベロシティ、届けたい機能。
分かっていないこと： これらの機能を届けるのに、どれくらいかかるか？

機能に基づくリリース計画では（関連項目： スクラムのリリース計画）、要求される機能のストーリーポイントの合計を、ベロシティで割ります。これが、節目の提供や最終提供に必要なスプリント数の最初の予測です。整数のスプリント数に切り上げ、作業の進行とともに、範囲とベロシティの前提を検査します。そして、その結果に基づいて計画します。

日付に基づくリリース計画

分かっていること： チームのベロシティ、届けたい日付。
分かっていないこと： 締め切りまでに、どの機能を届けられるか？

日付に基づくリリース計画では、ベロシティに、リリース日までのスプリント数を掛けます。その日までに届けられる、ストーリーポイントの合計の予測が得られ、それに基づいて計画します。

機能と日付に基づくリリース計画

分かっていること： チームのベロシティ、届けたい機能、それらを届けたい日付。
分かっていないこと： 指定された期限までに、要求された機能を届けられるか？

ベロシティに、リリース日までのスプリント数を掛けます。その日までに届けられるストーリーポイントの合計の予測が得られます。これが、対象の機能のポイントの合計より大きければ、現在の予測では範囲が収まると考えられます。ただし、不確実性と変化の影響を受けます。

そうでなければ、範囲、日付、キャパシティの取捨選択を話し合います。人を増やしても、自動的にベロシティが上がるわけではなく、一緒に働くことを学ぶ間は、最初は遅くなることもあります。以前の九人という目安は、現在の厳格な上限ではありません。スクラムチームは、通常10人以下です。有効性が高まるなら、別のチームが並行して取り組めますが、同じプロダクトでは、一人のプロダクトオーナー、一つのプロダクトゴール、バックログ、完成の定義を共有します。

プロダクトバックログと同じく、リリース計画は固定された計画ではありません。理解が深まるにつれ、プロジェクト全体を通じて変わります。ストーリーの追加、削除、変更、それに伴う見積もりの変化も影響します。そのため、定期的に見直し、更新する必要があります。