プラクティス名（別名）
ベロシティ （スループット）
プラクティスの目的・狙い
- チームの開発速度を定量的に把握する
- チームのキャパシティやリリース時期の予測精度を高める
- チームの状態把握、改善のための指標にする
どんな時に使うか
- チームのパフォーマンスを知りたい時
- いつごろリリースできそうか知りたい時
- （スプリント回数が固定の場合）どこまでPBIを拾えそうか予想したい時
実施手順
ベロシティとはそのスプリントで完成させたPBIのストーリーポイントを合計した数字です。ベロシティを計測するには、各PBIのSPが見積もられていることが前提となります。（カンバン方式などでSPを用いず、チケット数や作業時間でカウントする場合は単にスループットと呼ぶ場合が多い）
- これまでに完成したPBIのSP合計を実施スプリント数で割り、ベロシティの平均値を算出する
- スプリントプランニングでPBIを選ぶ際、SP合計がベロシティを大きく上回ることがないように加減する
- リリースプランを立てる際、残PBIのSP合計とベロシティから、あと何スプリントぐらいで完成しそうかを予測する
- ベロシティが乱高下する場合は、チームの開発力（もしくは見積精度）が低い可能性があるため改善を図る
- 改善策の効果はベロシティの変化で見極める
アレンジ例
- 直近3スプリントの平均値をチームのベロシティとする
- イレギュラーな要因で極端に低い/高い数字が出てしまったスプリントは集計から除く
アンチパターン
- ベロシティをチームの生産性とみなして、上がり続けることを期待する
- ベロシティを他チームと比較したり、個人の評価に用いる
- ベロシティを対外的な報告に用いる
PO初心者はチームに対して常に最高のベロシティを出すことを求めがちですが、数字にこだわりすぎるのも良くありません。ベロシティの上がり下がりに一喜一憂せずに、多少の誤差はつきものと心得て、傾向を知るための目安として取り扱いましょう。
グッドハートの法則
ベロシティを上げることが目的化してしまうと、DEVはSP見積りを水増しするなどして数字上は改善したように見せるようになってしまいます。実質的には何の意味もなく、むしろ測定の精度が悪くなるだけです。ベロシティに限らず評価に用いられる指標にはこういった力学が働いてしまいます。それを避けるためにはアジャイル宣言にあるように"動くソフトウェアを進捗の尺度"とすることです。
参考情報
Agile Studioさんのサイト（豆知識がマニアックで素敵です）
RyuzeeさんのRSGT2024の登壇資料
こぼれ話（私的コメント）
プラクティス一覧上の分類について。「ベロシティ」はあくまでも実績ベースの数字なので、「見積/計画」ではなく「進捗/点検」のカテゴリとしました。ベロシティは実績値である、という前提はとくに重要だと思います。
以前こんな質問をされたことがあります。「いつもは2週間スプリントで10営業日あるのですが、今回は祝日が2日あって8営業日しかありませんでした。当然ベロシティは下がってしまうので、計算上は1.25倍して8→10日分に換算して計上してもよいでしょうか？」 僕の回答としては「換算してはいけない。なぜなら換算した瞬間にその数字は実績値ではなく理論値に成り下がってしまうから」です。理論値はあくまでも仮説であり、事実ではありません。この数字はまぎれもない実績です、と言えなくなってしまうのは痛いなぁ、と考えたからです。
そもそもベロシティの出所となるSPって幅のある数字です。例えば8spといっても5よりは大きいが13よりは小さいという意味でしかなく、厳密な8ではありません。もともと厳密でない数字を換算して厳密にしようとしても、あまり意味はない気がします。
それよりはありのままに見せて、「何故ベロシティが下がったのか？」と問われたら「8営業日だったので」と理由を答える方がシンプルではないでしょうか？