■ はじめに
Scrum の 見積もり について扱う。
目次
【１】ストーリー ポイント (Story point; SP) １） ストーリーポイントの付け方 補足１：ストーリーポイントの基準の一例 補足２：Tシャツサイズ 【２】ストーリー ポイント算出方法 １）プランニングポーカー 【３】ベロシティ（Velocity） １）注意点 【４】バーンダウンチャート（Burn-down chart） 【５】Scrumの見積もり １）見積もるための式
【１】ストーリー ポイント (Story point; SP)
* 作業(プロダクト バックログ項目、ユーザーストーリー)を 完全に完了するために必要なコストを見積もる指標
補足：ユーザーストーリー
https://dk521123.hatenablog.com/entry/2021/02/18/000000
より抜粋 * システムがユーザに対し、提供する価値を説明したもの => テンプレートとして 「<who>として、<what>を達成したい。それは<why>だからです」
１） ストーリーポイントの付け方
* 一般的には、「1, 2, 3, 5, 8, 13, 21, 40...」などのフィボナッチ数 を使う場合が多い => 最大は、チームの方針次第っぽい（8だったり13だったり、、、）
補足１：ストーリーポイントの基準の一例
* あくまで一例。 => ここでは、「Min：1 ～ Max：13」とする
SP = 1 の場合
* やり方が見えていて、すぐ（その日中？）完了できる作業
SP = 2 の場合
* やり方が見えているが、ちょい（2～3日位？）時間が掛かりそう
SP = 3 の場合
* やり方が見えているが、時間が結構掛かる
SP = 5 の場合
* やり方が見えていなくて、調査が必要。 でも調べれば何とかなりそう。 * やり方は見えているが、仕様調整などで時間が掛かる
SP = 8 の場合
* やり方が見えてなくて、調査が必要。 調査してもできないかも。
SP = 13 の場合
* やり方も見えないし、調査必要。 調査してもできないかも。 なおかつ、相当面倒で時間が掛かりそう
補足２：Tシャツサイズ
Tシャツのサイズ（XS、S、M、L、XL、XXL。場所によっては、単純にS～L） によって、 寄り分けていく。 => Tシャツサイズからストーリー ポイントへの変換は、XS=1、S=2、...など して変換していけばいい。
【２】ストーリー ポイント算出方法
１）プランニングポーカー
* 作業項目の規模を見積もる手法 * Scrum Teamが集まって、各項目ごとに 各自の思う規模をストーリー ポイントとして 一斉に提示する => 全員が一致した場合、そのストーリーポイントが採用 => 一致しない場合、なぜその値を選んだのかを発表し （最高点の人と最低点の人のみの場合が多い）再び一斉に提示 => 全員の値が一致するまでこの工程を繰り返す
プランニングポーカーのカード例
| カード | 意味 |
|---|---|
| 0 | [1]既に完了しているアイテム [2]あまりにも小規模過ぎてサイズを示す必要ないアイテム |
| 1/2 | 非常に小さいアイテム |
| 1,2,3 | 小さめのアイテム |
| 5,8,13 | 中規模アイテム。目安として1スプリントの最大サイズ13とする。13より大きい場合はアイテムを分割 |
| 20,40 | 大規模アイテム |
| 100 | 非常に大きいアイテム又はエピック(※) |
| ∞（無限大） | あまりにもデカ過ぎて数字を当てはめられない |
| ？ | [1]チームメンバが内容を把握できないアイテム(別途POからの説明が必要) [2]見積もり辞退(全然想像もつかない場合) |
| π（パイ） | ちょっと疲れたからそこらのパイ食うか的なアイテム(3.1415...ではない)。優先度が低く、空き時間にやるようなアイテム |
※ 用語整理
| 用語 | 説明 |
|---|---|
| エピック | より小さなユーザストーリーで、分割できるまとまった作業 |
| ユーザストーリー（ストーリー） | 要件またはリクエストをエンドユーザーの観点から簡潔にまとめた作業 |
【３】ベロシティ（Velocity）
* スプリント期間で、スクラムチームの作業を こなせる速度を数値化したもの => 進捗状況を計る目安となる cf. Velocity = 速度
１）注意点
* ベロシティは、スクラムチームごとに異なる => ということは、メンバーの入れ替わりにも影響する
【４】バーンダウンチャート（Burn-down chart）
* プロジェクトの残りの作業量と その作業を行うための時間をグラフ化したもの => 「実績線」「計画線」「理想線」で表示され、 プロジェクトの進捗状況が計画から どのくらい離れているのかを一目で分かる
【５】Scrumの見積もり
プロダクトバックログの項目を見積もれば、 プロジェクトの先行きを見通することができる
手順
[1] プロダクトバックログの項目から、作業項目に落とし込む [2] その作業項目にスプリントポイントを見積もる [3] スクラムチームは、1スプリントで作業をこなしてみる [4] そのスプリントで何ポイントこなせたか実績値(ベロシティ)がでる [5] プロダクトバックログの全項目のスプリントポイントとベロシティにより その全項目に必要なスプリント数（期間）が見積もれる => 「１）注意点」で述べたようにベロシティは変化するので、 [3] ~ [5] を繰り返す => バーンダウンチャート でグラフ化しておけば、 どういう状況になっているのか把握しやすい
１）見積もるための式
[1] [絶対に必要な項目の見積もり合計] ÷ [ベロシティ] = [必要なスプリント数 (期間)] [2] [ベロシティ] × [期間内に実施できるスプリント数] = [実現可能なSP (どこまで実現可能かが分かる)] => 式[1] を変形しただけ
関連記事
スクラム開発 ～ 入門編 ～
https://dk521123.hatenablog.com/entry/2019/10/31/222447
スクラム開発 ～ 基本編 / チーム ～
https://dk521123.hatenablog.com/entry/2021/02/17/000000
スクラム開発 ～ 基本編 / イベント ～
https://dk521123.hatenablog.com/entry/2021/02/19/000000
スクラム開発 ～ 基本編 / バックログ ～
https://dk521123.hatenablog.com/entry/2021/02/18/000000
スクラム開発 ～ ワーキングアグリーメント ～
https://dk521123.hatenablog.com/entry/2023/01/13/222626
スクラム開発 ～ インセプションデッキ ～
https://dk521123.hatenablog.com/entry/2023/01/23/162537