org

ストーリーポイントを効率よく見積もる為に

ストーリーポイントはどのように見積もっていますか？PO がユーザーストーリーを紹介した上、各自が手元のプランニングポーカーから一枚を引き（もしかしたらアプリかもしれません）、「せーの」と唱えった後おもての数字を見せ合います。もし違いが存在していたら、互いに説明をし、最終的に同じ数字に揃えるようにします。とても定番的なやり方ですよね。しかし、そのやり方を貫くだけで、上手く行くとは限りません。例えば、A さんが 1 を出しているものの、B さんがその数字をはるかに上回った 5 とかを出しているケースが頻出していたら、回し方に問題が潜んでいるはずです。自分の経験上、以下の 3 点に関する問題が起因となった可能性が高いです。

バックログアイテムがうまく作成されていない

正確なストーリーポイントが出せていないというのはあくまで事象で、そもそも土台に当たるバックログアイテムが見積もりにくい状態になっていることはよくあります。バックログアイテムの完成度を判断するのによく使用されているのは「I.N.V.E.S.T」という基準です。要するに、取り扱いやすいアイテムは以下の基準を満たさなければいけません。

  • Independant (独立している)
  • Negotiable (交渉できる)
  • Valuable (価値がある)
  • Estimatable (見積れる)
  • Small (サイズが小さい)
  • Testable (検証できる)

ネット上「I.N.V.E.S.T」を説明する良い記事がたくさん存在している為、細かい説明は割愛しますが、ここで Independant と Estimatable に注目したいです。例えば、「上のアイテムを完成しないと、下のアイテムが見積もれないよ」という言い方はよく聞きます。それは恐らく独立性の不足を表している証拠です。上手く切ったユーザーストーリーなら、お互いに干渉しないし、不確実性の急増がしません。

また、Estimatable も大事です。ストーリーポイントを出す前、開発チームが見積もる対象のスコープと情報を理解していなければ、正しい見積もりが出せません。もしバックログアイテムが見積もりにくいと感じたら、リファインメントもしくはプランニング 1 のタイミングで開発チームと PO が擦り合わせを行うべきです。

ストーリーポイントの定義に関する理解が異なっている

ストーリーポイントを効率よく出す為に、ストーリーポイントの定義をしっかり理解するという前提条件があります。ストーリーポイントと時間の関係性を説明する記事が世の中にいっぱい出回っていますが、理論上ストーリーポイントと時間は換算できないし、すべきではありません。ストーリーポイントはチームの努力を相対的に表している単位で、投資しなければいけない時間はあくまで参考基準の一つに過ぎません。技術的なチャンレンジが含まれているユーザーストーリーは当然ながら大きな努力を要しますので、時間だけで考えるとストーリーポイントの趣旨と異なってしまいます。

正確には、ストーリーポイントを通して見たいことはバックログアイテム間の差です。仮にアイテム A のストーリーポイントは 1 で、アイテム B のストーリーポイントは 5 でしたら、アイテム B を消化させる為に 5 倍ほどの努力をしなければいけないことを意味します。PO はそれを重要な参考材料とした上でアイテム間の順位を決めることになります。さらに、もし前スプリントにおいてアイテム B を消化できたものの今スプリントでは５ポイント消化できなかったら、それを振り返り時の客観的材料として利用することができます。ストーリーポイントの定義を正しく理解していなければ、当然ながら見積もりが上手くいかないはずです。

見積もる際に考える軸が定まっていない

上記の前提条件をクリアしたとしても見積もりが上手くいかなかったりします。議論の内容を聞けばわかるはずですが、ストーリーポイントを出す時考慮した要素が異なるケースは度々現れます。例えば、A さんが仕様の複雑性を配慮し 3 を出したが、B さんが技術上実現しやすいという考えで 1 を出したりします。無論話し合いにより抜けた観点が補完され、最終的に目線が合わせられますが、効率性を考えれば、最初から合わせた方が有益でしょう。すなわち、ストーリーポイントを見積もる際に考慮したい軸を事前に共有しあい、みんながそれに従って考えることで観点の抜け漏れを未然に防ぐイメージです。ここで二つの考え方を紹介したいと思います。

一つ目はMike Cohn 先生の定義に従った考え方です。ストーリーポイントを見積もる時、以下の三要素から考えるイメージです。

  • 作業量
  • 複雑度
  • 不確実性またはリスク

この考え方の実用例として Michael Lant さんの Effort Matrix があります。上記の 3 つめの要素、不確実性を複雑度へマージしたマトリクスです。

Effort Matrix

この手法に関するモチベーション、やり方およびフィードバックは Michael Lant さんのブログにて詳しく紹介されていますので、詳細はそちらをご参照ください。

もう一つはStacey matrixの思想を借りて、仕様難易度（Requirements）と実装難易度（Methods）二軸で考えることです。下記の図は実用化されているメトリクスを表しています。縦軸は仕様難易度で横軸は実装難易度です。緑は「セーフティゾーン（Safety Zone）」、黄色は「ハザードゾーン（Hazard Zone）」で、赤は「デンジャーゾーン（Danger Zone）」です。

Story Point Matrix

仕様難易度が 2、実装難易度が 3 でしたら、ストーリーポイントが 5 点になり、ハザードゾーンに入ります。すなわち、許容できるものの、できれば避けたい粒度です。もしストーリーポイントの結果がデンジャーゾーンに落ちたら、アイテムの分割が上手くいっていないと考えられます。運用している際に、仕様難易度はちょうどユーザーストーリーの What 部分に当たり、実装難易度は How の部分に当たるため、イメージしやすいと評価されていました。

最後に

上記の内容はあくまで経験則に過ぎないので、全てのチームに合致しているとは考えにくいです。例えば、成熟しているチームなら、わざわざ二軸に分けてストーリーポイントを考えることはむしろ過剰だと思います。結局のところ、自分のチームへ最も相応しい方法を見つけ出すことは一番大事ですよね。

参考記事