スプリントプランニング(Sprint Planning)とは
スプリントプランニングとは、選択されたプロダクトバックログアイテムをこれから実行するスプリント内で実現するために、やるべきことをタスクに分解し、そのタスクを見える化するスクラムのセレモニーの１つです。スクラム全要素についてはこちら。
プロダクトオーナー、開発チーム、スクラムマスターが基本的に参加しますが、プロダクトオーナーは、最初の30分ほどでも良いかも知れません。これから実行するスプリントで実現するプロダクトバックログアイテムをチームがサインアップしたものが何かを把握し、開発チームと合意するところまで。スクラムガイドでは、スプリントプランニング１と２と区別していますが、区別しないやり方もあるようです。
- スプリントプランニング1 : 優先順位が高いプロダクトバックログアイテムをチームが選択する。選択したものをスプリントで実装することをプロダクトオーナー、開発チームで合意する。
- スプリントプランニング2 : 選択されたプロダクトバックログアイテムを、開発チームがタスクに分解し、見える化する(=透明性を高める)。
スプリントプランニングの成果として、スプリントバックログが出来ることが必要です。
プランニングの基本的な流れ
スプリントプランニング1
- POとプロダクトバックログアイテムの選択
スプリントプランニング2
- 開発チームの使える時間・カレンダーの確認
- タスク分割
- スプリントバックログ作成
- POと最終合意
目安の時間
スプリントプランニング1は、30分程度、
スプリントプランニング2は、1週間スプリントだと、およそ2～8時間、2週間スプリントだと4～16時間かかると言われていますが、どれだけ時間がかかってもそのスプリントの計画をきっちり建てることが大切です。ここにタイムボックスはありません。
心構え
- タスクは、30分～1時間、最大でも5時間程度(1日以内でやりきれる時間)の粒度まで分解し、計画をします。（よく、このタスクの時間をプランニングポーカーしているチームを見かけますが、見積もり時間はプランニングポーカーするレベルのものではないです。もっと厳密に見積もります。プランニングポーカーをするのは、もっと粒度が洗いもの、プロダクトバックログアイテムのポイント決めで使うことがあります）
- 受け入れ基準の再確認をします。また、設計行為をしてしまいます。コードのどの部分をどう直す、まで決めるイメージです。クラス図やシーケンス図をホワイトボードに書きながら、アーキテクチャを見える化し、そのままそこにタスクの付箋を貼っているチームもありました。まさにプランニング！
- 開発チームがこのスプリントで使える時間を計算し、全タスクがその時間内に収まっているかを把握します。もし溢れてしまった場合は、プロダクトオーナーと共有し、入りきらないリスクがあることを伝えます。それでもやってみるのか、プロダクトバックログアイテムをいくつか落とすのかを相談します。
- DONEの定義を確認しながら進みます。
- 一つのプランでうまくいかないリスクがある場合は、開発チームは複数プランを建てます。
効果的・効率的にやるには
これまでスクラムマスター・アジャイルコーチを数年やってきて、色々なチームを見させてもらっていますが、どこのチームも最初はプランニングが辛いと言っていました。辛くないチームは、結構属人化が進んでしまっている傾向があります。チームのあるメンバーしかそのタスクが取れない、という場合には、そのメンバーがタスク分解したら共有して終わりって感じなので辛くはないんです。時間も短く済みます。ただ、それが本当のチームなのかというと、そうではないですよね。
チーム全員で共有しながら、理想的には誰でもそのタスクが取れる状態になり、且つスプリントプランニングを効果的・効率的にやる方法はあります。
一言で言うと、全員の脳を常により動かしておく状態にすることです。
どうすれば、全員の脳を常に動かしておけるのでしょうか。
- スプリントプランニングをワークショップ形式にする
- デジタルツールを使わない
- 常に対話が生まれる状態にする
などがありますが、実は他にもたくさんのアイディアや原則があります。
困ったらスクラムマスターに相談しましょう！
開発チームによって特有のやり方、事情があるでしょうから、一概にこの方法がベストプラクティスだとは言い切れません。
個別にご相談にも載れますので、ご連絡いただければと思います（笑