開発が終わる予定日だけでは、利用者がいつ何を使えるかは伝わりません。
リリース計画(Release plan)は、提供する目的と範囲、対象利用者、時期、公開に必要な条件を整理する計画です。
開発作業の予定に加え、使い始めるための準備を扱います。

提供する変化を示す

たとえば、予約サービスへ、利用者自身が日時を変更する機能を追加するとします。
すべての予約で提供するか、一部の店舗で先行して試すかを決めます。
変更できる期限や、対象外の予約も利用者へ伝える必要があります。
機能名だけでなく、誰が何をできるようになるかを共有します。

公開へ必要な条件

必要な検証、データの移行、利用者への説明、問い合わせ対応、監視を確認します。
予約変更の例なら、重複予約や通知の失敗が起きた際の対応も用意します。
公開を小さく始める場合には、対象を広げる判断と、問題があった場合に止める条件を決めます。
予定日に合わせ、未確認の品質条件を黙って対象外へ移さないようにします。

見込みと約束を分ける

時期が不確かな場合は、何を前提にした予測か、どの条件が残るかを示します。
残作業、過去の完成状況、使える能力から見直し、情報が増える時点で更新します。
外部へ日付を約束する場合は、その影響と変更する判断の経路を確認します。
単に希望する日付を計画へ書いても、実行可能性が高まるわけではありません。

スプリントとの区別

スプリントは、スクラムで成果を作り検査する固定期間です。
リリースは、その期間内でも行えるため、必ずスプリントの終了日と一致するわけではありません。
一方、複数の成果や外部の準備がそろう必要があるなら、その依存を別途管理します。
必要な完成の定義を満たすことと、公開する時点の判断も区別します。
公開後は、利用と問題を確認し、次のプロダクトバックログや運用の改善へ反映します。

参考資料