プラクティス名
リリーススプリント
プラクティスの目的・狙い
- リリース作業に必要な期間を確保する（リリース前後の不随タスクを含む）
どんな時に使うか
- そのスプリント中にリリース作業があるかどうかでベロシティが乱高下してしまう
- PBI消化作業とリリース作業が並走することでミスが頻発し、障害を誘発してしまう
実施手順
- 通常のスプリントとは別にリリース作業専用のスプリントを設ける（期間は任意）
- 本スプリント中はリリース作業に専念し、PBIの消化は原則行わない
- スクラムイベントの開催も任意とする（が、デイリースクラムぐらいは続けた方がよい）
本来、スクラムの理想としては全ての作業を通常スプリント中に消化すべきである。
しかし現実問題として、リリース手続きや事後フォローを考えると、PBIを消化しつつそれらの作業をこなすことが難しいことがある。リリース作業に集中し、それだけを確実にやり遂げた方がよい場合にこのプラクティスを適用する。
アレンジ例
- 週次サイクルを崩さないためリリースススプリント期間を1週間とし、余った日は技術調査や環境改善などに充てる
アンチパターン
- 何でも後回しにしすぎて、リリーススプリント自体が長期化する
- リリーススプリントでやるから、と全く手をつけていなかった非機能要件テストで致命的な問題が発生し、リリース自体が中止になる
参考情報
こぼれ話（私的コメント）
「リリーススプリントが必要なのはUndoneタスクを溜め込んでいるからでは？」
「そもそもリリーススプリントという考え方自体がアンチパターンなのでは？」
そんな批判の声が聞こえてきそうなプラクティスではあります。ですが、例えばウォーターフォールから移行したてのチームや、パイプラインも組めていないような環境下では、どうしたって通常のスプリント内で安定的にリリースすることに無理があるケースもあります。理想と現実の狭間を埋めるために編み出された工夫を、単に「教科書通りではないから」という理由で否定したくありません。確かにやり方としてベストプラクティスではないかもしれませんが、チーム全員で話し合い、自分たちの現場では今はこれが必要だという結論に至ったならば、それがベストな判断のはずです。ベロシティ計測としても通常スプリントとは別扱いにした方が都合がよいと思います。