スプリントで扱うプロダクトバックログアイテム数は何本がいいのか

スクラムのスプリントで扱うアイテム数は何本がいいのだろうか？

スクラムガイドのスプリントプランニングのトピック1：スプリントで何ができるのか？には以下の記載がある。

開発チームは、スプリントで開発できそうな機能を予想する。プロダクトオーナーは、スプリントで達成すべき目的と、完成すればスプリントゴールを達成できそうなプロダクトバックログアイテムにつ いて検討する。スクラムチームはみんなで協力して、スプリントの作業を理解する。

スプリントプランニングのインプットは、プロダクトバックログ、最新のプロダクトインクリメント、開発チ ームが予想するキャパシティと過去の実績である。プロダクトバックログから選択するアイテム数については、開発チームが責任を持つ。スプリントで何を達成するかを評価できるのは、開発チーム だけである。

プロダクトバックログから選択するアイテム数については、開発チームが責任を持つ。スプリントで何を達成するかを評価できるのは、開発チーム だけである。

これは、スプリント毎の作業量については、開発チームが決めると言うことである。スクラムでは、アイテム数を最低3本とか最大20本にせよとか具体的には何も定義していない。だから開発チームは1本だけ選んでも良いし、30本選んでもいい。過去の実績（昨日の天気）を基準に、現実的なアイテム数を選べば良い。

チームによって、そしてインダストリーや扱うドメインによっても最適な本数は様々だろう。だが、少なすぎる本数と多すぎる本数は避けたほうがいい。

一本だけのケース

プロダクトバックログアイテムをスプリントにひとつだけ投入するケースである。これは成果がゼロになるリスクがあるので避けた方がいい。0か１、いちかばちかのスプリントになってしまうので、スクラムチームだけでなく、スポンサーやステークホルダーも安心して見ていられない。成果が安定しないし、ギャンブル的な怖さがある。

多すぎるケース

たとえばプロダクトバックログアイテムを30本選ぶケースである。これは成果は安定しやすい。0~30まで細かく刻んでいるのだから、スプリント毎に20本できた、16本できた、24本できたのように詳細なデータが取れる。アイテム数であれポイントであれベロシティとしても意味のあるメトリクスが取得できる。

このケースの課題は、個人ワークが増えてしまうことだ。仮に開発チームが5名だとすると、単純計算で1人あたり6本割り当てられることになる（30アイテム/5人）。タスクボードでは最初から5本のバックログが同時並行で走ることになる。そこには、最上位のアイテムをよってたかって倒していく概念はない。まずは自分に割り当てられたアイテムを完了させて、余裕があればチームを助けるという動きになりがちだ。スクラムでは、開発チームは相互に作用しながら顧客にとって最大価値のアイテムから届けていく。アイテム数が増えると、ペアワークやモブプログラミングを避けて、個人レベルで量をさばく意識がでてしまう。チームレベルの学習機会もないから、現状スキルのまま漠然と作業をこなすだけのロボット人間になってしまう。

チームやプロダクトドメインに依存するから一概に言えないが、私の経験では１週間スプリントなら３~７アイテムあたりがいいように思う。バックログ粒度と数を実験しながら、チームにとって最適なアイテム数を探索して欲しい。