こんにちは、開発2部のTashです。
この記事では、スクラム開発を取り入れたアジャイルの現場で特に印象に残っている
スプリントプランニングとタイムボックスの考え方について、実務視点で振り返ります。
【アジャイル開発 #2】では、各イベントの全体像を紹介しました。
今回はもう一歩踏み込み、「その場で何をどう判断していたのか」に焦点を当てて書いていきます。
▼前回の記事はこちら。
【アジャイル開発 #2】 スクラムイベントを通して分かった、チームの動き方
スプリントプランニングは「2部構成」
私たちのチームでは、スプリントプランニングを第1部・第2部の2部構成で行っていました。
なお、1スプリントは2週間です。
第1部：リファインメントのおさらいと変更点の共有
第1部では、プロダクトバックログリファインメント（PBR）の内容をベースに、
- プロダクトバックログリファインメント後に発生した変更点
- 新たに追加された作業
- やらなくてよくなったもの
を中心に確認します。
「前提条件が変わっていないか」
「認識がズレたままになっていないか」
を揃えるための時間、という位置づけでした。
第2部：開発チーム主体での作業分解と見積もり
第2部では、開発チームが主体となり、
- PBIをサブタスクに分解する
- 各作業のおおよその所要時間を見積もる
といった作業を進めていきます。
作業を細かくしていく過程で、第1部では見えていなかった疑問点が出てくることも多く、
その都度、プロダクトオーナーやプロダクトオーナーアシスタントに質問が回ってくるため、
開発チーム主体とはいえ、他の役割も気が抜けない時間でした。
キャパシティという考え方
スプリントプランニングで特徴的だったのが、
作業時間を「キャパシティ」として扱っていたことです。
私たちのチームでは、定常的に発生するイベントの時間をあらかじめ差し引いたうえで、
1スプリントで実際に使える時間をキャパシティとして算出していました。
そのキャパシティの範囲内に、
サブタスクの作業時間見積もりが収まるかを確認し、
「理論上できそうか」ではなく、
「現実的にできるか」という視点で精査していきます。
タイムボックスを「割合」で捉えるという考え方
アジャイルの中で、個人的にとても印象に残っているのが
タイムボックスを“割合”で見る考え方です。
例えば、
30分と見積もった作業が15分遅れた場合。
感覚的には、
「15分くらいなら、そこまで大きな遅れではない」
と思ってしまいがちです。
でも、見積もりに対して考えると、
これは50％のオーバーになります。
時間の長さそのものではなく、
見積もりとのズレをどう捉えるか。
この視点は、これまでの自分の感覚とは大きく違っていて、とても印象的でした。
タイムボックスがもたらした変化
タイムボックスを意識するようになってからは、
「遅れたこと」そのものを問題にするよりも、
- なぜズレたのか
- 見積もりが適切だったか
- 前提条件に抜け漏れはなかったか
といった点を、チームで冷静に振り返ることが増えていきました。
また、キャパシティを基準に考えることで、
「とにかく詰め込む」のではなく、
このスプリントで何をやり、何をやらないかを精査する
という判断が、少しずつできるようになっていったように感じます。
ここまでを振り返って
スプリントプランニングやタイムボックスは、
単なる進行管理のための仕組みではなく、
チームで現実を直視するための道具なのだと思います。
次回の記事では、
半年間アジャイル開発に関わってきた中で感じた価値や変化、
そして今後の課題について、もう少し視点を引いて振り返ります。
