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

 2011/03/16
このエントリーをはてなブックマークに追加

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

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

Success Factors in a Scrum Sprint

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

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

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

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

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

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

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

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

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

なお、元記事のグラフにあるように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以上の見積りを持つプロダクトバックログ項目は原則として分割するルールにしました。

まとめ

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

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

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

 2011/03/16
このエントリーをはてなブックマークに追加