本記事ではストーリーポイントについてのお話しをまとめます。
少し扱うトピックが狭いようにも思いますがおそらくスクラムをしている多くのチームで見積もりをする際に議論になるポイントでもあると思いますのでどなたかの参考になればと思っています。
スクラムとフィボナッチ数列
スクラムにおいては見積もりをする際に相対ポイントとしてストーリーポイントを使ってそれぞれのアイテムを見積もります。その際に多くのチームでは使用するポイントはフィボナッチ数列にある要素(数)を利用しているようです。フィボナッチ数列は以下のような数列ですね。
1,1,2,3,5,8,13,21,34,55,・・・ 出典：フィボナッチ数列とは。一般項の証明・黄金比との関係について
チームによって様々だとは思いますが、あまり大きな数値は使わないでしょう。フィボナッチ数列の性質上、例えば13の次は21、21の次は34、と徐々に隣の数値との差が大きくなっていくことも理由かと思います。小さくタスクを分割していくことで見積もりをしていくことがスクラムのフレームワークの方針としてもあるのですが21や34といった大きな数値は多くのケースで大きすぎる見積もりであると認識されるでしょう。
そういった場合はアイテムを分割することを検討します。見積もりが31、21では大きすぎるのでもう少し小さくタスクを分けよう、という形ですね。
僕の感覚としては13より大きな見積もりは分割する必要があるかな、という認識です。
リファインメントとフィボナッチ数列
上述のようにフィボナッチ数列を参考に見積もりをしていくことがベストプラクティスです。
一方でそこにこだわりすぎると無駄な時間を使いすぎるケースもあると思います、実際に僕もよくありました。それはこういったケースです。
- Aさん：僕はこの作業は8ポイントだと思うな
- Bさん：私はこれは13ポイントだと思うんだけどな、8ポイントの作業量ではないのではないですか？
- Aさん：うーん、そうですかね。僕はそう思わないな、なぜなら・・・
- (Aさん、Bさんを中心に議論が長引く)
あくまで一例ですがこういった議論は多くのスクラムチームで起きているでしょう。
まずはじめに断っておくと、この議論は非常に大切だと僕は思っています。Doneの定義の認識がずれていたり、Doneの定義の内容自体をアップデートする必要性があったりすることが根本原因のこともあるでしょう。
また、そもそも実は見積もりをする段階ではなくReadyの状態ではない、そういったことが原因で認識の違いが起きているのかもしれません。その際はReadyとすべく情報を集めなければいけないケースもあります。そして場合によってはReadyの定義の整理をする必要もあるでしょう。根本的に対策をするとすれば例えばこういったことが必要かもしれません。ただ、これらはやり始めると非常に時間がかかることです。
そのため、状況によってはフィボナッチ数列にこだわらずこのケースの場合では間をとって10ポイントとすることで議論を終わらせることも一つの方法だと思います。見積もりはあくまで見積もりである、という認識が取れていればこういった手段を取ることもできるでしょう。僕はよくこの方法をとります。
一方で上述したように根本の原因を棚上げしているケースもあるため、それらは別の機会にしっかりとアプローチする必要があります。それは忘れないようチームで取り組むべきことです。
さて、本記事はこれで以上です。ストーリーポイントを用いた見積もりは非常にいい方法だと思います。ただ、スクラムチームが議論する点はいくらでもありますので特にスクラムマスターは限られたリソース(特に時間)をうまく使うようフォーカスすべき課題に集中するようチームをリードできるといいですね。スクラムについては下記記事でもまとめていますので合わせてご覧ください！
