はんなりと、ゆるやかに

アジャイル、スクラムが好きなITエンジニアが日々から学んだことをアウトプット

「ストーリーポイント」は「荷物運び」でたとえると分かりやすい

スクラムではプロダクトバックログアイテムを見積もるときに「ストーリーポイント」という単位を使います。

見積もりと言えば、「このタスクは2時間」「このタスクは7時間」といった時間🕒の絶対値で見積もることが多いと思います。「ストーリーポイント」は基準となるタスクから相対値で見積もります。

例えば、「ログイン画面を作る」をストーリーポイント「2」と決めて、「〇〇画面を作る」は開発部分少ないから「1」とか、「〇〇機能を追加する」は影響範囲が多いから「5」とかです。


ここで疑問がわいてきます。なぜ時間で見積もらず、まわりくどく「ストーリーポイント」で見積もるのか。どんな良いことがあるのか。


そこでピンっときたのが、ストーリーポイントを「荷物運び」でたとえてみる。です。

「荷物運び」と「ストーリーポイント」

f:id:iucstscui:20201210230449p:plain

ある地点からある地点まで大量の荷物を運ぶ必要が出てきました。この時、荷物の運ぶ時間を見積もることが時間見積もりです。荷物の重さを見積もることがストーリーポイントを使った見積もりです。

荷物を見積もろう

重さを見積もるのに「はかり」があれば正確に測れますが、過去の経験から見積もらないといけない場合、「これは10.235.kg」「これは2.173kg」と正確に見積もるのは困難ですよね。「これは10.235.kg、いや、10.245.kgか?、いや、・・・」なんてやっていると時間がもったいないですし、どうせ間違えます。また、直感で見積もっても時間かけても見積もっても、正確性に差が出ることは少ないです。こういうことを「収穫逓減の法則」と言います。

そこで見積もり時間短縮に有効な手段が相対見積もりです。基準となる荷物の重さを「2」と決めます。あとは簡単です。「これはちょっと重いから「3」。こっちは軽いから「1」」とぱっぱっぱっと見積もっていくのです。ただ、これも細かくし過ぎると見積もり時間がかかるので「1,2,3,5,8,13,21」のフィボナッチ数列を使われることが多いです。基準から遠い荷物はきっと正確な数値を出せないので選べる値も極端にします。

また、複数人で見積もる場合にもストーリポイントの利点がでます。
時間見積もりは同じ2キロの荷物でもAさんは1時間、Bさんは3時間、と能力によって見積もり結果に差が出ます。じゃあ、あいだ取って2時間にしようかってすると、どちらが作業しても見積もりミスになります。また、関係性によっては1時間で押し切られて、Bさんが作業したら大幅な見積もりミスになります。こんなときもストーリーポイントであれば荷物の重さを見積もるので個人能力で差が出ません

さらに、見積もりの差について話し合うことで作業の漏れや余計な作業をしようとしていることに気づけます。
Aさんが2kg、Bさんが10kgと大きく差が出た場合、「この荷物を運ぶときは合わせてこれもセットで運ばなきゃいけないんだよ。」「そうなの!?」って暗黙知を可視化できるのです。
f:id:iucstscui:20201210234639p:plain

全部運び終わるにどれぐらいかかるか予測しよう

時間で見積もった場合、1つひとつの見積もり時間を足せば「後50日で終わりそうだ。」と予想が立てられます。そして、1日目から遅れていくのです。

ストーリーポイントの場合、運ぶ重さは分かりましたが、どれくらいで運び終えられるかは分かりません。だから、とりあえず、運び始めます。1日目運んでみたら「10ストーリーポイント」運べることが分かりました。じゃあ、残りは「900ストーリーポイント」だから後90日で運べそうだとわかります。

ただ、時間で見積もった場合も1日目終わったあとにリスケをすれば良いので、結果は変わらないと思います。ただ、予想より2倍かかりそうって分かったら荷物1つ1つの見積もり時間を修正していく作業が発生しますし、上司やステークホルダーに「すみません、間に合いそうにないです。」と気が重い報告しなくちゃいけません。時間で見積もったら正確に見積もれたって気がしますが、そうでもないです
f:id:iucstscui:20201211003458p:plain

スクラムは時間固定で開発するから、ストーリーポイントの方が改善結果が分かりやすい

カイゼンマインド」を持ち、前よりもっと成長したいと思いながら開発していると思います。その場合、「成長したかどうか」を計測することが大切になります。

スクラムで開発する場合、1週間とか、2週間とか、固定の期間で繰り返し開発します。この固定期間で完了した数値をベロシティと呼びます。

開発期間は固定なので時間見積もりの場合、集計できる対象は荷物の数になります。荷物の数をベロシティにする場合、軽い荷物を13個運んだ日と重い荷物を1つ運んだ日でベロシティが異なります。何か改善しても次の日の運んだ荷物によってはベロシティが下がる可能性があります。「あれ?効果なかったかな?」っとなるのです。

ストーリーポイントの場合はその合計がベロシティです。ストーリーポイント「1」の軽い荷物を13個運んだ日と、ストーリーポイント「13」の重い荷物を1つ運んだ日で同じベロシティになります。(どちらも13)

たとえば筋肉がついて運べるスピードが上がった場合、1日のベロシティが「10」から「15」に変わって成長が見えます。また「荷台を購入する」という画期的なアイデアにより運べるスピードが格段に上がった場合も「10」から「30」と大きな成長が見えるのです。
f:id:iucstscui:20201211002425p:plain

まとめ

  • ストーリーポイントは荷物運びでたとえられる
  • 荷台は荷物を運ぶのに役立つ

参考にした記事

www.ryuzee.com
qiita.com