今さら聞けないストーリーポイントの基本

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

スクラムをはじめとしたアジャイル開発の見積りでよく使われるのがストーリーポイントです。ストーリーポイントは研修でもよく聞かれるテーマであるとともに、誤解も多いものなので、今回基本からまとめて解説したいと思います。なお、文脈の前提として、スクラムでの活用を想定しています。

【警告】スクラムチームにおいて「もっと正確に見積りたい」とか、スクラムチーム外から「正確な見積りが欲しい」と言われるような場合、見積り以外のところに問題があります。チームの現状や、ステークホルダーのアジャイルやスクラムに対する理解や期待をいまいちど検査することを強くお勧めします。

ストーリーポイントとは？

まずは、ストーリーポイントとは何なのかを見ていきましょう。

書籍『アジャイルな見積りと計画づくりー価値あるソフトウェアを育てる概念と技法』（Mike Cohn 著、安井力、角谷信太郎訳、マイナビ出版、2009/1/29）の61ページから62ページにかけて、ストーリーポイントは以下のように定義されています。

ストーリーポイントとは、ユーザーストーリーやフィーチャ、その他の作業の大きさをあらわす単位である。ストーリーポイントを使った見積りではそのような、ひとまとまりの作業に対してポイントを付ける。ポイントの数値そのものはあまり重要ではない。重要なのは、他の作業との相対値だ。2ポイントを付けられたストーリーは、1ポイントのストーリーの2倍の大きさであり、3ポイントのストーリーの3分の2の大きさとなる。ストーリーポイントの数値は、ストーリー全体の規模をあらわす。ストーリーの規模を定義するための数式は存在しない。ストーリーポイントによる見積りが示す値は、フィーチャを実装するのに必要な作業、開発内容の複雑さ、開発に内在するリスクなどが渾然一体となったものである。

また、書籍『More Effective Agile ー"ソフトウェアリーダー"になるための28の道標』（Steve McConnell 著、長沢智治監訳、クイープ訳、日経BP、2020/6/11）の209ページでは以下のように定義されています。

ストーリーポイントは作業アイテムの大きさと複雑さの目安となる基準である。 (略)ほとんどの場合、アジャイルチームはストーリーポイントの尺度として1～13のフィボナッチ数列（1,2,3,5,8,13）を使用し、各作業アイテムのサイズをストーリーポイントで割り当てる

これらを踏まえると、ストーリーポイントとは対象の規模や大きさを表す相対的な数値であり、複雑さやリスクを踏まえたものである、と言えます。

なお、前者の定義にもあるとおり、必ずしもユーザーストーリーに特化したものではなく、対象物をポイントで見積もるというのが意味するところです。

スクラムとストーリーポイントの関係

スクラムのルールはスクラムガイドで定義されています。中身を読んで頂くと分かりますが、スクラムガイドのなかには、ストーリーポイントという単語も、ユーザーストーリーという単語も登場しません（初版となる2010年版ではTipsのなかで「ユーザーストーリー」が登場しましたが、2011年以降はありません）。

スクラムガイド2020年版で関係しそうなところを見てみましょう。

プロダクトバックログ
プロダクトバックログは、創発的かつ順番に並べられた、プロダクトの改善に必要なものの一覧である。これは、スクラムチームが行う作業の唯一の情報源である。
1スプリント内でスクラムチームが完成できるプロダクトバックログアイテムは、スプリントプランニングのときには選択の準備ができている。スクラムチームは通常、リファインメントの活動を通じて、選択に必要な透明性を獲得する。プロダクトバックログアイテムがより小さく詳細になるように、分割および定義をする活動である。これは、説明・並び順・サイズなどの詳細を追加するための継続的な活動である。多くの場合、属性は作業領域によって異なる。
作業を行う開発者は、その作業規模の評価に責任を持つ。開発者がトレードオフを理解して選択できるように、プロダクトオーナーが開発者を支援することもできる。

ここから分かることを確認しておくと

プロダクトバックログアイテムの書き方は、スクラムでは定義していない
作業規模の評価の方法についても、スクラムでは定義していない

ということになります。つまり、スクラムにおいて、「ユーザーストーリー」を使うのは単なる実装の1つであり、作業規模の評価に「ストーリーポイント」を使うのも実装の1つに過ぎません。別にユーザーストーリーでプロダクトバックログアイテムを記述しなくても構わないですし、ストーリーポイントで見積りをしなくても構いません。プロダクトバックログアイテムの記述にユースケースを使ったり、自分たちが分かりやすい形式を作ったりしてもよいですし、見積りにTシャツサイズ見積り（S、M、L、XL）を使ってもよいわけです。

とはいえ、ストーリーポイントは便利なことも多いので、次はそれについて見ていきましょう。

ストーリーポイントの使いどころ

ストーリーポイントは計画づくりや予測、そして改善に役立ちます。ここで新たな用語が登場します。それがベロシティです。ベロシティもスクラムガイドで定義されていない用語ですがよく使われます。

ベロシティとは、1つのスプリント（XPの場合はイテレーション）のなかで完成したアイテムのストーリーポイントを合計したものです。たとえば、5ポイント、3ポイント、2ポイントのアイテムが完成した場合は、ベロシティは10ポイントになります。

ベロシティが分かれば、計画のときにその値を参考にして計画を立てたり、将来を予測したり、改善に役立てたりすることができるようになります。

スプリントプランニングに活用する

前回のスプリントでのベロシティが10であれば、今回のスプリントで完成できる量も10ポイント程度ではないかと予測できます。これによって、完成できないようなたくさんのプロダクトバックログアイテムをスプリントプランニングで議論・計画したり、スプリントに投入したりするのを防ぐことができます。

また過去のスプリントのベロシティがあれば、さらに予測の精度は上がります。たとえば、過去3スプリントのベロシティが、10ポイント、14ポイント、12ポイントの順に安定的に推移していた場合、おおよそ12ポイント程度の完成は確度が高いと考えられるようになります。

一方で過去のベロシティの推移が、10ポイント、0ポイント、20ポイントのように乱高下している場合は、数字のばらつきが大きいため、必ずしも予測の精度は高くならず、チームがなんらかの問題を抱えていることを示唆している可能性もあるので注意が必要です。

中長期的な予測に活用する

ベロシティはスプリントプランニングだけでなく、中長期的な予測にも活用できます。主に以下のように使います。

残りのスプリント回数がおおよそ決まっているときに、どこまで達成できそうかを予測する
実現する必要があるプロダクトバックログアイテムが決まっているときに、何スプリントかかりそうかを予測する

前者については、「残りスプリント数 * 直近のベロシティの平均値 = 残り期間で完成できそうな量」となり、後者については、「実現する必要があるプロダクトバックログアイテムのストーリーポイントの合計 ÷ 直近のベロシティの平均値 = 必要なスプリント数の概算」となります。

これらはあくまで概算ですが、同じチームで開発している期間が長くて、ベロシティが安定しているようであれば、それなりに精度は高くなります。一方で、新しいチームを作ったばかりの状況などで、ベロシティが乱高下しているような状況であれば、精度は低くなります。つまり、チームが成長し安定するにつれて予測の精度は高くなるものであり、最初から正確な予測をすることは不可能です。

ステークホルダーに見通しを伝えるときは、一度きりではなく頻繁に伝えましょう。たとえばスプリントレビューで毎回見通しを伝えるのもよいでしょう。

改善のために活用する

スプリントレトロスペクティブの場などで、ベロシティやストーリーポイントのデータを使って改善点を探すこともできます。いくつか例を挙げましょう。

ベロシティが乱高下している場合、その理由を深掘りする
- 上述のとおり、ベロシティが乱高下していると予測の役に立ちません。乱高下している理由を明らかにして改善していきます
- ありがちなのが、毎スプリントで着手したものの完成しなかったプロダクトバックログアイテムが多数あり、それを後続のスプリントで完成まで持っていくといった良くないやり方をしていることです
- これはプロダクトバックログのリファイン（具体化、分割、その他準備）が十分でない可能性や、スクラムの理解不足の可能性を示唆しています
ベロシティが緩やかに下がっていたり、以前と比べて低くなったりしている場合、その理由を深掘りする
- 同一のストーリーポイントのアイテムは、おおよそ似たような作業量になるはずにも関わらず、以前よりもベロシティが下がっている場合、なんらかの問題があるかもしれません
- たとえば、コードベースが複雑になってしまい、以前より簡単に作業できなくなったとか、テストが手動のためにテストの工数のインパクトが大きくなってしまったといったものです
- ほかにもさまざまな理由が考えられますが、放置してもよくならないので、根本原因を見つけて対処していきます
あるストーリーポイントを超える規模のアイテムが完成しないことが多い場合は、自分たちの扱えるサイズに分割すべきサインだと考える

これらはあくまで一例なので、チームで議論してみるとよいでしょう。なお、このとき、ベロシティやストーリーポイントの数字だけを見て一喜一憂するのは無意味です（「前のスプリントよりも1ポイント上がった！バンザイ！」のようなものは無意味です）。ストーリーポイントは、あくまで概数であり誤差はあります。検討の材料の1つとして傾向をとらえるようにしましょう。

よくある質問

ここまでストーリーポイントの概要について見てきましたが、ここからはありがちな質問を取り上げます。

他のチームとストーリーポイントやベロシティを比較できますか？

一部の例外を除いてできませんし、比較しても無意味です。スクラムチームの外側にいるマネージャーやなんとか管理部門の人たちが、ベロシティを比較したいと言ってきたら全力で止めましょう。異なるプロダクト同士では、そもそもストーリーポイント1ポイントが示すサイズ自体が違います。あるチームの1ポイントが、他のチームの2ポイントくらいに相当することもあるでしょう。あくまで相対的な値なので単純比較はできません。

唯一の例外は、同一プロダクトで同じプロダクトバックログを元に作業するチームが複数存在する場合です。この場合は、ストーリーポイント1ポイントが示すものは、チームを横断して共通になるので、比較はできます。ただし、比較してどうしたいの？という点が明確になっていなければ無意味です。

ベロシティの目標値を設定する是非について教えてください

目標値を設定したところで、チームの能力が劇的に上がるわけではありませんし、ベロシティが上がるわけでもありません。つまり無意味です。たとえば、厳しい予算や期間があるプロダクトにおいて、一定の範囲を終わらせるには、最低でも1スプリントあたりのベロシティが30ポイント必要だ、みたいな計算をすることはないわけではありません。ただ、それを達成できるかどうかはやってみないと分かりません。数スプリントやってみて、実際のベロシティの平均が10ポイントだということが分かれば、その時点で別の対処をしなければいけません。

それでも目標ベロシティの達成を要求するとどうなるかというと、見積りのときに大きく見積もるだけです。ベロシティを倍にするいちばん簡単な方法は、すべてのストーリーポイントを2倍にすることです。もちろん無意味ですが。

開発する人が違えば見積りは変わると思うんですが？

ストーリーポイントの定義をもう一度確認しましょう。相対的な規模感を表すものであり、それは開発する人によって変わるものではありません。開発する人によって変わるのは、実際の所要時間です。

この質問をしているということは、プロダクトバックログアイテムを先に個人に割り当てて、割り当てられた個人単位で見積もっているのではないでしょうか？そのようなやり方はよくありません。リーンの原則に従うと、同時の仕掛かりをなるべく少なくして、すばやく完成させていくことが重要ですが、プロダクトバックログアイテム単位で分業してしまうと、完成しないリスクがとても高くなります。プロダクトバックログアイテムは開発者全員で見積もりましょう。

初期の段階でいつリリースできるかを予測するのにストーリーポイントは使えますか？

使えなくはないですが、正確ではないので、随時リリース予測のアップデートが必要です。いくつかの要因があります。

初期の段階のプロダクトバックログはそもそも精度が低い
- プロダクトバックログは開発期間中ずっと変わり続けます。初期の段階のプロダクトバックログはかなり精度が低く、不要なものがたくさん混じっていると考えるのが妥当です
初期の段階の見積りもそもそも精度が低い
- プロダクトバックログに含まれる全量を把握するために見積りをしても、まだ内容に対する理解も不十分だったり、プロダクトバックログアイテムに対する共通理解がない状態だったりすれば、見積りもほぼ適当です
初期の段階ではベロシティが分からない
- 同じチームでずっと仕事をしていて、過去のプロダクトでの見積りを基準にして今回のプロダクトを見積もった、という場合以外は、ベロシティは分かりません

これらを踏まえると、初期の段階での予測はいまある材料を使った「適当な予測」ということになります。適当な予測がまったく役に立たないわけではありませんが、これが約束として扱われる状況であれば極めて危険です。時間が経つにつれて精度が上がっていきますので、見通しは何度もアップデートしてください。