プラクティス名（別名）
エンドゲーム （最終リリーススプリント）
プラクティスの目的・狙い
- 最終本番リリースやプロジェクト完了作業に専念できるようにする
- 負の遺産を次に引き継がない
どんな時に使うか
- 最終スプリントはいつも慌ただしく、後できちんと整えようと思ったいた部分にも手が回らず、中途半端な状態でプロジェクトが終了してしまう（＝結果として負の遺産が大量発生する）
実施手順
- 最初のプロジェクト計画の時点でスプリント実施期間とは別に「エンドゲーム」の期間を確保しておく
- エンドゲームの期間はスプリントのタイムボックスと同じでなくても構わない（個別に設定する）
- エンドゲームの中でもプログラム改修は行ってよいが、機能追加は原則行わない
- スクラムイベントの実施もマストではない（が、デイリースクラムぐらいは続けた方がよい）
- スプリント中に後でやろうと思っていて結局できなかった事やプロジェクト完了に必要な手続きを行う
エンドゲームの作業例：
- リファクタリングや不要コンポーネントの整理（ゴミ掃除）
- 品質やセキュリティを高めるための追加テスト（※本来はスプリント中に行うべき）
- 最終本番リリース作業
- ドキュメントの整備
- 保守運用チームへの引継ぎ
- プロジェクト全体のふりかえり
- 残課題の取り扱いに関するユーザ合意
- プロジェクト完了報告
- 契約完了手続き
など
アレンジ例
- 連続して次のプロジェクトが始まる（＝スプリントも継続する）場合でも、改善点を洗い出すためにエンドゲームを挟む
アンチパターン
- エンドゲームでやろう、と何でも後回しにする
- エンドゲームをバッファと同一視し、スプリントの続きを行ってしまう
参考情報
「エンドゲーム」の出典は以下の書籍です。MARVELのアレじゃないです。
こぼれ話（私的コメント）
要はUndoneタスクや技術的負債を吐かせて次のプロジェクトに悪さを引き継がないための布石です。契約の切れ目ではPBLに載らないタスクも諸々発生するので、最終スプリントだけ妙にベロシティが低い、とならないように切り分けるという意味もあります。最終スプリントのバタバタの中で本番リリースするとミスが増えるので、落ち着いてDEVが作業に専念できる期間を設けてあげようという心理的な要素もあるかもしれません。
理想としては全ての作業をスプリントの中で消化するべきなんでしょうけど、現実的には難しいので必要悪（？）として受け入れています。
マネージャーが指をパチンと鳴らしたら、次のプロジェクトではDEVが半数になっていた・・・なんて良からぬ想像をしてしまうのは僕だけでしょうか？