Blog

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

 2010/07/09
このエントリーをはてなブックマークに追加

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

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

ベロシティとは

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

ストーリーポイントとは

チームや案件によって何を1ストーリーポイントにするかは異なります。

例えば基準値の決め方としては、1番小さいと思われるプロダクトバックログ項目を抽出し、それを1とするやり方や、基準値を決めるときだけ、2日間と5日間で終わると思うプロダクトバックログ項目を抽出し、それを2および5のストーリーポイントとして定義する(注:ただし以降の計算時には一切ストーリーポイントを日付や時刻に変換するようなことはしないこと)といったやり方があります。 スクラムにおける見積りの特徴は、見積りをコストや体制や時間と直接リンクさせないことにあります。 開発チームは規模の見積もりをプランニングポーカーを使って行うのが一般的ですが、この際、参加者が見積りの数字という点で意思表示できるのは、見積り対象のプロダクトバックログ項目が、基準プロダクトバックログ項目と比較して何倍くらいなのか?という点のみです。 そこには、「自分が作ると8時間だが、スペシャリストの上司が作ると4時間で、外部の業者さんに発注すると16時間になるので、どうしようか?」みたいなブレは存在しません。 誰にとってもストーリーポイント2のプロダクトバックログ項目はストーリーポイント1の2倍(くらい)の規模であり、ストーリーポイント5のプロダクトバックログ項目は5倍(くらい)ということになります。

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

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

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

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

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

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

派生パターン

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

それでは。

 2010/07/09
このエントリーをはてなブックマークに追加