スプリントプランニングをうまくやるために意識していること
1年ほど専任のスクラムマスターとして活動してきて、スプリントプランニングがうまくいってるケースとうまくいってないケースについてなんとなく見えてきたのでメモとして残す。
スプリントプランニングの目的
自分の理解だとスプリントゴールを達成するための実行可能な作業計画を作るのがプランニングの目的なので、以下の3つが達成できているかを気にしている。
- チーム全員がスプリントバックログとして分解した全てのタスクについて「何をするタスクか」「完了条件は何か」が理解できている
- キャパシティに収まる計画になっている（収まらないのであればプロダクトバックログアイテム(PBI)の分割などといった調整が必要）
- リスク・不確実性のあるタスクがない。もしくはスプリントの早い段階でクリアになる計画となっている
うまくいってないチーム
うまくいってないチームはプランニングで「ゴール達成のための実行可能計画を作る」ことができておらず、行き当たりばったりな計画になっていることが多かった。
そういうチームが作るスプリントバックログの兆候としては
- 「調査」「設計」のようなタスクがPBI毎に存在する
- 「バックエンド開発」「画面の実装」など曖昧で、有識者しか具体的に何をするのか理解できないもの
- 1つ1つのタスクの見積もりが2日などかなり長い
- そもそも見積もりをしていない（アジャイルだから計画いらないよね？みたいな。。）
あたり。
スプリントプランニングをうまくやるために
現状で意識していること。
プランニングの時間
実行可能な計画を作るのが一番の目的。チームの練度が低い段階だとプランニングにかける時間はあえて気にしない方が良さそう。 スクラムガイドには
スプリントが 1 か月の場合、スプリントプランニングのタイムボックスは最大で 8 時間である。 スプリントの期間が短ければ、スプリントプランニングの時間も短くすることが多い。
とあるが、時間を気にするのはプランニングがうまくできるようになってからが良いと思う。
タスクの粒度
チーム結成直後やチームにJoinしたばかりのメンバーがいる場合は、タスクの粒度を2h以内まで。（場合によっては1hでも良いかも）
理由としては、
- 各タスクの曖昧さを無くしチーム全員が同じ認識を持つため
- 予想外のことが発生した場合にデイリースクラムなどで検知しやすくするため
タスクの内容
「設計」のようなタスクは排除。プランニングの中でモブワーク的に設計をしてもらう。
理由としては、
- 設計が終わっていない状態で分解したタスクは内容が曖昧になってしまうことが多い。→ 設計が終わってみないと本当にスプリント内で完了できるかわからなくなってしまう
- モブでやることで誰が何を「知っているのか」「知らないのか」が明確になる
進め方のイメージ
- クラス図などの絵を描きながら認識をすり合わせる
- 実際のコードを見ながら「このメソッドに処理を追加しよう」「XXXって処理を追加しよう」などの具体的に話しをする
- コードの実装箇所にコメントを入れておく
- APIやテーブル設計もこのタイミングでやっておく（あとはドキュメントに起こす、yamlファイル各だけみたいな感じ）
最後に
プランニングがうまくいくとチームとしてゴール達成のイメージを持ちやすくPOも安心感が高まる。 スプリントゴールの達成率が高まれば、チームとして不確実性の高いゴールにもチャレンジできるようになり、成功・失敗を通してチームの学習がより進む。
スクラムを始めたばかりのチームの場合はしっかりとプランニングを行うように促すと良いのではないだろうか。
