ベロシティを他のチームと比較してはいけない

みなさんこんにちは。@ryuzeeです。

前回目標ベロシティとベロシティのインフレという話をしました。そのときに触れなかったいくつかの話題について、追加で説明します。

ベロシティとは

ベロシティとは、1スプリント中に完了したプロダクトバックログアイテムの見積りの合算値のことです。プロダクトバックログアイテムは、あらかじめ見積りが終わっている必要があることを意味します。

ストーリーポイントとは

チームによって何を1ストーリーポイントにするかは異なります（注: 複数チームで1つのプロダクトを開発し、プロダクトバックログが1つの場合は共通の基準とします）。

例えば基準値の決め方として、1番小さいと思われるプロダクトバックログアイテムを抽出し、それを1とするやり方や、基準値を決めるときだけ、2日間と5日間で終わると思うプロダクトバックログアイテムを抽出し、それを2および5のストーリーポイントとして定義する（注: ただし以降の計算時には一切ストーリーポイントを日付や時刻に変換するようなことはしないこと）といったやり方があります。

スクラムにおける見積りの特徴は、見積りをコストや体制や時間と直接リンクさせないことにあります。

開発者は規模の見積りをプランニングポーカーを使って行うのが一般的です。この際、参加者が見積りの数字という点で意思表示できるのは、見積り対象のプロダクトバックログアイテムが、基準となるプロダクトバックログアイテムと比較して何倍くらいなのか？という点のみです。そこには、「自分が作ると8時間だが、スペシャリストの上司が作ると4時間で、外部の業者さんに発注すると16時間になるので、どうしようか？」というようなブレはありません。

誰にとってもストーリーポイント2のプロダクトバックログアイテムはストーリーポイント1の2倍（くらい）の規模であり、ストーリーポイント5のプロダクトバックログアイテムは5倍（くらい）ということになります。

なぜベロシティを他のチームと比較してはいけないのか？

もう答えは書いてしまっていますが、チームによってストーリーポイント1の基準が異なるからです。

そして異なる基準の数値を比較するための変換係数を用意することは、問題領域や開発している物が異なるため極めて困難であり、たとえ定めたとしても妥当性を評価できません。唯一比較しやすそうなケースは、1つのプロダクトバックログを複数のチームで実装していくようなスクラム・オブ・スクラムのケースです。この場合は基準となるストーリーポイントは同一で、完成の定義も同じであるため、異なるプロジェクト間よりは比較しやすくなります。

それでもチーム間で比較するとどうなるのか？

前回の記事のパターンと良く似たことが起こります。すなわちストーリーポイントのインフレです。他のチームより数字が多ければ良いからです。

インフレが続くと、「統一した単位で数値を計算するように」などということを言い出す人がいるかもしれません。その際に絶対さけるべきであるのに使われてしまう単位は「時間」です。こうなるとウォーターフォールの問題点に逆戻りです。

派生パターン

比較という点でよく聞かれるのが、「ウォーターフォールとアジャイルでの生産性の比較はどうしたら良いんですか？」という質問です。これも上のパターンと同じです。変換係数がないので一意に比較はできません。おすすめは、顧客に満足度を聞きにいく、チームのメンバーの満足度を調査する、といった関わっている人にフォーカスをあてるものです。

それでは。