■ はじめに
https://dk521123.hatenablog.com/entry/2014/05/22/215203
で見積もりを扱ったが、 今回は、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だったり、、、）
２）ストーリーポイントの基準例1
SP = 8 の場合
* 2週間のスプリントで1人のエンジニアがフルコミットで 完了させられる作業
SP = 5 の場合
* 1週間のスプリントで1人のエンジニアがフルコミットで 完了させられる作業
SP = 3 の場合
* 2日のスプリントで1人のエンジニアがフルコミットで 完了させられる作業
SP = 2 の場合
* 半日のスプリントで1人のエンジニアがフルコミットで 完了させられる作業
SP = 1 の場合
* 数時間のスプリントで1人のエンジニアがフルコミットで 完了させられる作業
SP = 13 の場合
* スプリントで1人のエンジニアがフルコミットで 完了させられるのに2週間以上かかってしまう作業
ストーリーポイントの基準例2
* あくまで一例。 => ここでは、「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、...など して変換していけばいい。
【２】ストーリー ポイント算出方法
１）プランニングポーカー
* チームの開発者全員で担当する機能を見積もる時、 プランニングポーカー (フィボナッチ数列に基づくカード。1、2、3、5・・・。) を出し合って、見積もる参加型の見積もり技法。
手順
[1] 作業を行うメンバーを集め、 それぞれにプランニングポーカーカードを配る [2] ファシリテーターを決める （司会。スクラムマスタやプロダクトオーナーになる場合が多い） [3] ファシリテーターがユーザーストリーを読む [4] それぞれのタスクに対して開発を担当するメンバーが 思いのままに数字のカードを出し合う => 全員が一致した場合、そのストーリーポイントが採用 [5] 一致しない場合、なぜその値を選んだのか根拠を発表し （最高点の人と最低点の人のみの場合が多い）お互いにを述べ合う [6] 各メンバーの考えをシェアすることで、 一人で考えている時には漏れていたかもしれない 工夫や懸念材料を洗い出す [7] ディスカッションを終えたら、再度カードを出し合う [8] このサイクルを2、3回繰り返す（最大3回） → 全員がある程度、納得できる見積もりを出すことができる
プランニングポーカーのカード例
| カード | 意味 |
|---|---|
| 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] を変形しただけ
参考文献
プランニングポーカー
http://www.ryuzee.com/contents/blog/4664
http://enterprisezine.jp/iti/detail/3385
http://f.hatena.ne.jp/wayaguchi/20120218091121
http://congasoft.com/wp/wp-content/uploads/2014/04/planning_poker.pdf
関連記事
スクラム開発 ～ 入門編 ～
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
