前回は1スプリントの計画と日々の活動について書きました。
今回はプロダクトが完成した後の活動について書いていきます。

日々の活動を経て「リリース判断可能なプロダクト」が完成しました。
そのプロダクトが「リリース可能なプロダクト」かどうかを検証・判断するための会議を「スプリントレビュー」といいます。

■スプリントレビュー
この会議は、開発チームの成果物をプロダクトオーナーが確認する場です。
・開発チームが開発したものをPOにデモをする
・POはリリース可能かどうかを判断する

以前プロダクトバックログを作成する段階で、その要求に対する完了の定義を決めておきました。
今回のスプリント計画で開発することにしたプロダクトバックログ毎に、その完了の定義を満たしているのかどうか、デモを通じて検証します。

その結果を見てPOがリリース可能かどうかの最終判断を下します。
ここでNGになったプロダクトバックログについては、その残作業を次のスプリントに持ち越します。

NGになったプロダクトバックログを、スプリントの期間を延長して完了させるのではなく、次のスプリントに持ち越す点に注意して下さい。

これは開発チームの「ベロシティ」を測るためです。

■ベロシティ
スクラムのルールとして各スプリントの長さは均一にしなければなりません。
また、以前プロダクトバックログの見積もりを行う際にプランニングポーカーの手法を説明しました。
この手法で見積もりが行われた場合、それぞれのプロダクトバックログには、それを実現する場合にどれくらいの工数が掛かりそうかがポイントで表現されています。

つまり、1スプリントで消化できたプロダクトバックログのポイントの総計が、今の開発チームが1スプリントで消化できるポイントであり、今の開発チームの実力を表します。それを「ベロシティ」と呼びます。
このベロシティを測り、また比較するために、スプリントは均一でなければならないのです。

今の開発チームのベロシティがわかれば、今後のスプリント計画も立てやすくなり、プロジェクトの見通しも立ってきます。
開発チームとしてはベロシティ、つまりチームの実力を測る、その目安にもなります。

スクラムでは開発チームがベロシティを向上させるべく、次のスプリントへ向けて今回のスプリントをふりかえるための会議体が用意されており、それを「スプリントレトロスペクティブ」といいます。

■スプリントレトロスペクティブ（ふりかえり会）
次のスプリントを今回のスプリントよりも良くするためのアクションを決める
・プロセスやツールなどの観点で今回のスプリントを検査する
・うまく行ったこと、今後改善すべき点を整理する
・今後のアクションプランを作る

ふりかえりを行って次のスプリントに活かす、つまりPDCAサイクルを回すことで開発チームの業務を改善する仕組みが、スクラムには用意されています。

以上、ここまでが1スプリントで行う活動になります。

まとめますと、
・スプリント計画ミーティング
・デイリースクラムを実施しながらの日々の開発
・スプリントレビュー
・スプリントレトロスペクティブ
を1スプリント内で実施し、それを繰り返すことでプロダクトを作成していき、最終的にはそのプロダクトをリリースする、という流れになります。

今回を含め、今まで５回に渡りスクラム研修のまとめということで書かせていただきました。本連載は今回で終了です。

アジャイル開発におけるマネジメント手法の一つである「スクラム」。
その基本的なルールについては、本連載を書く中で改めて整理できたと感じています。今後はスクラムを実践しながら、更に学んでいければと思っています。

最後に、スクラムをはじめようと思っている方に向けて、スクラムの実践の手引とも言える、すばらしい書籍をご紹介させていただきます。
SCRUM BOOT CAMP THE BOOK

最後まで読んでいただき、ありがとうございました。