プラクティス名（別名）
リリースプランニング （リリース計画、リリース構想）
プラクティスの目的・狙い
- いつ頃、何がリリースできそうか、大まかな見通しを立てる
- ステークホルダー間の認識（期待）を擦り合わせる
どんな時に使うか
- 「いつ頃リリースできそう？」という質問に答える必要がある時
アジャイル開発におけるリリースパターンは大まかに３つ。
①スプリント毎にリリース／②スプリント数回毎に／③全スプリント完了後に
理想としては①ですが、リリースゲートなどの都合で現実的に難しいケースもある。そうなると②のある程度機能的にまとまった単位でリリースする、という選択をすることが多い。その場合、どこまで出来たところでリリースするか、という計画が必要になってくる。
実施手順
- PBLを作成し、優先順位付けとコスト見積もりを行う
- スプリント期間とチームのベロシティ（過去実績など）から各PBIの完成時期をざっくり見積もる
- リリースの準備期間（UNDONEタスク）や判定基準を加味し、仮のリリース日を定める
- スプリントが進み、正確なベロシティが測れてきたら、適宜リリースプランを見直す
PBLの変動は当然リリースプランにも影響するため、リリース予定日はあくまでも"現時点の見通し"として扱う
アレンジ例
- ユーザーストーリーマッピングを行い、1stリリース（MVP）、2nd、3rd・・・とリリースに必要なフィーチャー群を段階的に切り分ける
- フィーチャーに関係なく定期的にリリースタイミングを設け、その日までに間に合った分を順次リリースする
- 業務都合などでリリース日をズラせない場合はPBIの優先順位で調整する
アンチパターン
- 見積もりに時間をかけ過ぎる
- リリースプランを必達のマイルストーンとして関係者に確約する
→できればリリース時期は幅を設けて伝えた方がよい（例：1月中旬～2月上旬）
参考情報
こぼれ話（私的コメント）
リリースプランを考える際、「いつ頃」という観点のほか「誰に」という観点もあります。例えば一部のユーザにだけ先行利用してもらうパターンとかですね。その点については別のプラクティス（カナリアリリースなど）で取り扱おうかと思いますので、本稿ではひとまず割愛させていただきます。
ちなみに僕自身はQiita記事のリリースプランは全く立てておらず、日々気の向くままに投稿しております！