スクラムにおけるリリース計画

スクラム現場ガイドの第11章は全てを引用して載せたいぐらい良いことが書かれています。

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

プロジェクトにおいて、よく聞かれる質問「いつ終わる？」「この日までにできる？」

どんなプロジェクトでも、一番よく聞かれる質問は「いつ終わる？」「この日までにできる？」じゃないだろうか。誰でも、プロジェクトが予想通りに進まずひどい目にあった経験があるはずだ。

スクラム現場ガイド 第11章より引用

確かに頻繁に聞かれます。そしてステークホルダー（お金を出す側）にとってみれば最大の関心事はこれです。

伝統的な開発手法の場合、わかりやすく回答しやすい

ウォーターフォールなどの開発プロセスだと、要件が全て決まっていると仮定して、長いガントチャートを書きます。
長いガントチャートを書くために要件から機能をリストし、各機能を見積もります。この見積もりは仮定です。
ガントチャートを書き上げたら、その計画どおりに事が進むと仮定され、プロジェクトは開始されます。
ガントチャートがありますから、いつ何が完成するかは、チャートを見ればわかります。わかりやすいです。
そして報告では、計画通り事が進んでいないことが問題とされ、その問題（遅れ）を取り戻すための施策を検討せよ、ということになり、さらにプロジェクトは遅れます。
「数値上は、あと4人メンバーを追加すれば、計画通り進みます。」
と報告され、メンバーが4人追加され、さらにプロジェクトは遅れます。もう挽回は不可能です。
ただの「数合わせゲーム」と化します。
要件を削るか、期間を延ばすかです。
でもそれは不可能で、さらに人を追加します・・・。デスマーチです。

frontline.fm 言いたいことをいってくれている感がある（笑

スクラムの場合、何の準備もしていないと回答しづらい

逆にスクラムだとどうなるのでしょうか。
スクラムガイドラインにはこの手の回答はありませんので、自ら考える必要があります。

スクラムではガントチャートは基本的には引かないです。引いてもいいですけど頻繁に変わることを前提とするため、メンテナンスコストが多くかかります。
ガントチャートを引かない代わりに、以下の３つのインプットからリリースプランニングをします。

• 見積もり、順序付け、優先順位付けができているプロダクト・バックログ
• チームのベロシティ（チームと相談した上での、予測値。）
• スプリントのタイムライン

プロダクト・バックログのストーリーポイントが合計で200だったとして、チームと相談した仮のベロシティが20だとしたら、単純計算で10スプリントあれば完了です。
ただ、ストーリーポイントはスプリント毎に常に見直され、チームのベロシティもだんだんと安定してくることをステークホルダーと共有しましょう。
プロダクト・バックログの上から順に何がいつごろ出来そうかをプランニングします。

リリースプランニングの成果物は、以下の様な図になります。これがリリース計画になります。


リリース計画はプロジェクトのロードマップになります。
おおよそどのようなストーリーがいつごろ出来上がるかを視覚的にわかりやすく表現できています。

上記の例では、チームのベロシティは１つだけでしたが、チームの自信や経験を踏まえ、
最低・最大のベロシティにて計算すると良いと思います。（最低水位・最高水位と呼ばれています。）

さきほどの図に最低ベロシティの場合と最高ベロシティの場合を付けます。

表現を変えるだけですが、ストーリーポイントのバーンダウンに最低ベロシティだった場合の着地点と最大ベロシティの着地点を表現しても良いと考えます。

そして、このリリース計画をスプリント毎に必ず見直しましょう。
プロダクト・バックログ・リファインメント時が一番適していると思います。

この手法にて、スクラムにおいても「いつ終わる？」「この日までにできる？」に回答することができます。

何度も言いますが、このアプローチの場合に重要なのは、
リリース計画は毎回変わるものだということをステークホルダーと共有することです。

「計画は変わらないもの」「計画は死守するもの」として受け取られてしまうと「何が何でもスプリント１ではこのベロシティを出さなくてはならない」ということに成りかねません。
持続可能性が保持できません。

アジャイルとは、常に改善し続ける状態であること、です。
継続ができないということは、アジャイルではありません。

箱モノであろうが何であろうが、現在は明らかにサービスの時代です。エンドユーザに寄り添って、常により良いものを作り続ける必要があります。
エンドユーザとともに成長ができる、本当のWin-Winの関係が築けるのがアジャイルです。

リリース計画は初期のロードマップとして有効です。 計画は計画に過ぎないと、関係者の皆様が理解していないといけません。計画は変わるのです。私たちは最善を尽くしてプロダクトバックログを見積もりまますが、それでもプロジェクト完了までの実際の距離が予想より増えたり、減ったりいたします。
スクラム現場ガイド 第11章より引用