プラクティス名（別名）
ストーリーポイント （SP、相対見積り、規模見積り、ポイント見積り）
プラクティスの目的・狙い
- 個々の要件を実現するために必要な作業量（規模感/リスク）を迅速に見積る
- ベロシティ（チームの開発ペース）を計測可能にし、今後の見通しを立てる
どんな時に使うか
- リリース時期を予測したい時（SP合計とベロシティからスプリント回数を逆算）
- POがPBIの優先順位を決めるために、その機能の実装コストを知りたい時
- DEVが今回のスプリントでどこまでPBIを拾えそうか判断したい時
実施手順
前提として、ユーザの要求事項がストーリー形式でまとめられたリスト（スクラムでいうところのプロダクトバックログ）がすでにあるものとします。
- 見積基準とするPBIを選ぶ（これを「リファレンスストーリー」と呼ぶ）
- リファレンスストーリーがNポイントだとすると、こっちのPBIは何ポイントになりそうか、というサイズ比較によって作業量を見積もってゆく（これを「相対見積り」と呼び、それによってつけられる数値が「ストーリーポイント」）
- 要件の粒度が粗すぎてまだ見積れないPBIは、後日詳細化することを前提に大きめの数字を仮で割り当てておく（これを「エピック」と呼ぶ）
- 一通り見積れたら全体のバランスを見て、大小関係に違和感がないか確認する（同サイズのものを並べてみると分かりやすい）
- 開発の初期段階では不透明なことも多いため、適宜見直すことを前提に、見積りに時間をかけすぎないことが大切（精緻に見積ったとしても、前提が変わるとその労力が無駄になってしまう可能性が高い）
ストーリーポイントで使う数字
- フィボナッチ数（1,2,3,5,8,13,...）を用いることが多い
- 13または21以上をエピックとして扱うケースが多い（エピックにはあえて数字を入れないことも）
- 規模が大きくなるほど見積りのブレも大きくなるため、短時間で迷わず決められるように後にいくほどスケールを広げている
リファレンスストーリーの選択
- 最初はDEV全員が具体的に作業をイメージできる中規模のものを選ぶとよい
- 3spの場合はコレ、5spは～、8spは～と各規模に応じて設定しておけるとなおよい
相対見積りを使う利点
- 人間の特性上、絶対評価よりも相対評価の方が正確に見積ることができる
- 工数/時間などで見積る場合、誰がその作業をやるか（DEVの習熟度）を考慮する必要があるが、相対見積もりはタスク同士のサイズ比較であるため、その必要がない
- 開発初期と後期ではチームのパフォーマンス（ベロシティ）が変わってくるが、その場合でもsp見積りはやり直す必要がない（タスク規模自体は変わっていないため）
アレンジ例
- spの数値としてフィボナッチ数ではなく、2の乗数（1,2,4,8,16,...）を用いる
- spの数値の代わりにサイズ表記（XS,S,M,L,XL）を用いる（＝Tシャツ見積り）
- 目安として以下のようなストーリーポイントマトリクスを作成する
| SP | リファレンスストーリー | 複雑性・リスク |
|---|---|---|
| 1 | PBIxxx（文言修正等） | 無し |
| 2 | PBIxxx（設定変更等） | 低い |
| 3 | PBIxxx（機能改善等） | 低い |
| 5 | PBIxxx（簡単な機能） | 中 |
| 8 | PBIxxx（普通の機能） | 中 |
| 13 | PBIxxx（複雑な機能） | 高い |
| 21 | エピック（要分割） | 不明 |
アンチパターン
- 実際に開発を行うDEVが見積りに参加していない
- 「相対見積りの値」を時間/工数などの「絶対見積りの値」に変換しようとする
（→例えば、5sp＝10hとする、といった換算は原則として行わない。なぜなら5spは3よりは大きいが8よりは小さいという幅のある数字であり、かつ、作業者によっても実所要時間は変わってくるため） - 別チームのspやベロシティと比較する（そもそも基準が違うため比較できない）
参考情報
こぼれ話（私的コメント）
ストーリーポイントを見積もるための手法として「プランニングポーカー」や「Tシャツ見積り」などがありますが、具体的なやり方は別記事で紹介することとし、本稿ではまずストーリーポイントの概念と相対見積りの考え方にスポットしてみました。
sp見積りする際に、やや困るのが最初に選んだリファレンスストーリーのポイントをいくつにするか？ 前回と同じメンバーで臨む追加開発とかであれば、前回踏襲でよいし、皆の1spってこれぐらいという肌感覚もほぼ揃っているのですが、まったくの新チーム/新プロダクトだと、そうもいきません。まぁ、単純に決めの問題ではあるので、エイヤで決めて、あとは走りながら実績見て、適宜整えていくしかないんですけどね。
また、開発初期と後期でなんか3spの重みが違うなぁ、と感じる時、基準がブレているのか、チームの成長でそう感じるのか判断に迷うこともあったり。絶対見積りから相対見積りに変わっても、見積りに関する悩みはいつの時代も尽きないものだなぁと、常々思います。
余談ですが、この記事を何時間ぐらいで書けそうか、という見積りは6割ほど超過しました。見積りって難しい。(^^;)