“ストーリーポイント”で見積るメリット、“時間”で見積るデメリット

photo credit: Köpenhamn via photopin (license)

前回、見積りの時間を減らしたいなら「アジャイルな見積りと計画づくり」を読もうで見積りについて、紹介した。“ストーリーポイント”で規模を見積っているが、この“ストーリーポイント”を“時間”で置き換えている人をよく見る。“時間”で見積るのが悪いとは言わないが、それには非常に大きなデメリットがある。デメリットを理解して使っているのであれば問題ないが、理解せずに使っているのであれば、デメリットを紹介するので、参考にして欲しい。

“ストーリーポイント”で見積るメリット、“時間”で見積るデメリットの例

Q. 皇居1周を一緒に走ろうと話している3人グループがいる。
しかし、見積りで意見が分かれてしまった。

A「皇居1周なら30分だね」
B「ん? 1時間じゃね?」
C「えっ? 45分でしょ?」
一同「デタラメなこというんじゃない!!」

誰が正しいのだろうか?

上の例の答えをすぐに書くが、誰が正しいのかというと、実は全員正しい。

A「皇居1周は約5kmで、自分なら30分で走れる」
B「確かに皇居1周は約5kmだが、私だと1時間かかる」
C「そうだね、皇居1周は約5kmだけど、俺には45分かかるよ」
一同「皇居1周は約5kmには同意する」

人によって走る速度が違うように、ソフトウェア開発でも人によって開発速度が違う。そのため、“時間”の見積りで合意するには全員が全く同じ開発速度である必要がある。しかし、規模(上の例では距離)は人によって異なるわけではない。そのため、規模なら合意できるので、“ストーリーポイント”で規模を見積る。基準の規模で合意できれば、将来新しく出てきたフィーチャーに対する見積りでも合意できる。

他の“時間”で見積るデメリット

合意し難いというデメリットを上記の例で書いたが、他にも実はデメリットがある。このデメリットは“ストーリーポイント”で見積っているつもりが、“時間”で見積っている場合に起こる。

しばらく前のポイントが小さくなったと感じたことはないだろうか?

しばらく前のポイントが小さくなったように感じるのは自分たちが成長しているからだ。皇居1周走ろうとしていた3人は常に10km/h、5km/h、7.5km/hではなく、何度も繰り返し走っていれば走る速度はある程度上がる。同様に、ソフトウェア開発でも繰り返し開発をしていると、開発速度が上がる。

A「このフィーチャーって前の5ポイントと似てるよね」
B「でも今ならそれ半日もかからないでできちゃうよ」

A「最初の見積りに入って今までやらなかったこのフィーチャー13ポイントって書いてあるけど、
今なら半日でできるよね?」
B「そうだね、じゃぁこのフィーチャー5ポイントに変えちゃおうか」

上記発言の2つとも、作業単位を開発速度で割った“時間”と考えている部分がある(半日もかからない、半日でできる)。

しかし、開発速度は上でも書いたように繰り返し開発すると上がってしまう。そんな変わってしまう物差しで見積りをすると、最初に見積った“ストーリーポイント”とイテレーションをある程度繰り返してから見積った“ストーリーポイント”が変わってしまう。

開発速度はベロシティ(=イテレーション内で消化した“ストーリーポイント”数)で測れるのだから、それを“ストーリーポイント”を見積る際の物差しには使わない方が良いだろう。

まとめ

  • 人によって開発速度が違うので、“時間”で合意するのは難しい
  • 規模は人によって違わないので、規模(“ストーリーポイント”)で見積りに合意する
  • 開発速度で“ストーリーポイント”を見積りがちだが、最初とある程度イテレーションの進んだ後の見積りで異なってしまうので開発速度で見積るのは避けた方が良い