チームサイズ・スプリント期間・プロダクトバックログアイテム数について

みなさんこんにちは。@ryuzeeです。

Peter Stevens氏が行ったオンライン調査（調査母数は85）をもとにしてチームのサイズとスプリント期間とプロダクトバックログアイテムの数におけるスプリントの成功への関連について以下で述べているので、それを元に考察してみましょう。

なお、ここで言っているスプリントの成功とは以下のように定義されています。

「良いチームはオーバーコミットもアンダーコミットも(あまり)しないという考えのもとに、成功＝チームがコミットしたプロダクトバックログアイテムを全てデリバリできた、ということを指すこととする」

チームのサイズとスプリント期間

2週間スプリントを採用しているチームが規模に関わらずもっとも多く、半数以上を占めています。 4週間以上という回答もあるようですが、これはスクラムとしてはいただけません。

チームの規模が小さい場合や、プロダクトバックログアイテムの粒が小さい場合はさらに短い1週間スプリントは採用しやすいです。一方で、人数が多いチームでは、必然的に開発するプロダクトバックログアイテムの物理量が多いであろうことから、1週間スプリントだとスプリントプランニングやスプリントレビュー、レトロスペクティブのオーバーヘッドや、不測の事態（メンバーの急な休暇）への対応等で、慌ただしさを感じることが多い気がします。

個人的に1週間スプリントを採用しても良いチームは以下のようなチームだと考えます。

インハウスのサービス開発等でプロダクトオーナーやステークホルダーが近くにいていつでも捕まえられる
プロダクトバックログアイテムの物理サイズ(見積りのストーリーポイントではなく、1ストーリーポイントあたりのコードサイズや開発時間)がそれほど大きくない
チームのサイズがそれほど大きくない
既にある程度の期間チームが存続していて、チームの成熟度があがっている
一方でチームがレトロスペクティブで出したアクションアイテムに外圧を受けずにすぐ対応できる
ビジネスニーズの変動が大きい

また4週間等の長い期間を採用する条件としては以下のようになるでしょう。

それなりに大きな規模の開発
プロダクトバックログアイテムの物理サイズが大きい
完成の定義において製品の完成の基準が細かく定められている。もしくはパッケージソフトや生命に関するシステムのように品質基準を高めにおいている
チームに十分な経験がある
スクラム・オブ・スクラムや分散開発

なお、元記事のグラフにあるように4週間スプリントでは「成功」の割合が低くなりました（母数も少ないですが）。

プロダクトバックログアイテムの数

2週間スプリントで6〜8項目、3週間スプリントで4〜5項目がピークになっています。母数が少ないので2週間より3週間のほうがピークのサイズが小さいことは誤差と考えても良いでしょうが、いずれにせよ、20項目を超えることはなく、10項目程度が平均です。

なお、僕が以前にやった案件（5人チームの2週間スプリント）でのプロダクトバックログアイテム数は以下のとおりです。

第1 11
第2 8
第3 6
第4 9
第5 17
第6 17

当然のことですが、プロダクトバックログの優先度の高いものからスプリントプランニングでスプリントの内容を決めており、プロダクトバックログアイテムの見積りのサイズに大小の差があるので毎スプリント同じ項目数ということはありません。第3スプリントでプロダクトバックログアイテム数が少ないのは規模の大きいプロダクトバックログアイテムに対応していたからですが、プロダクトバックログアイテムの数が少なすぎると、そのスプリントで出荷できない大きなプロダクトバックログアイテムができてしまう可能性があります。プロダクトバックログアイテム数が少なすぎる場合は、適切なサイズでのプロダクトバックログアイテム分割が望ましいケースが多くあります。この時の例ではストーリーポイント13以上の見積りを持つプロダクトバックログアイテムは原則として分割するルールにしました。

まとめ

いずれにしても、チームがコミットしたプロダクトバックログアイテムを届けられていないケースは調査の中でも十分に多くあります。この元記事における成功の定義には疑問がありますが、タイムボックス化した中での見積りにおいてもコミットした内容をデリバリできないことがあるという点については認識すべきです（短期間でもコミットしたものがデリバリできないのに、どうして長期間でそれができると思うのでしょうか)。

当然のことですが、チームのベロシティはチームの成熟度によってはスプリント毎の変動が激しいので、レトロスペクティブやその他の機会にチームのベロシティを正しく把握し、次のスプリントではどうなるのか予測をするべきです。毎回コミットしたものをデリバリできないのであれば、チームのベロシティはそのチームや顧客が期待するよりももっと低いし、オーバーコミットしなければならない文化である可能性もあります。

プロダクトバックログアイテムは大きすぎてはいけません。見積りがフィボナッチ数列になっているのには理由があるのです。

アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください（初回相談無料）