http://martinfowler.com/bliki/XpVelocity.html

ベロシティは、大まかな作業量を経過時間と結びつけて、計画の目安にするというものである。ベロシティとは、一定期間でチームが（個人のベロシティであれば、ひとりが）どれだけの作業を成し遂げたかを大まかに表したものだ。ベロシティは「昨日の天気の原則」に従い、これまでの作業量から決定する。通常、過去3回分の平均値から、未来のベロシティを決定することが多い。元々はエクストリームプログラミングで提唱されたものだが、現在ではあらゆるアジャイルソフトウェア開発において広く使用されている。

たとえば、2週間のイテレーションで働いているチームが、ストーリーポイントを使ってストーリーの作業量を見積もっているとしよう。最初の3つのイテレーションのベロシティは、20、30、27だった。このとき、チームのベロシティは26になる。この数値を使って未来を予測するには、まずは最初のリリースまでに完成させたいストーリーを合計する。たとえば、ここでは330としよう。すると、現在の計画では、26週間（330 / 26 => 13イテレーション）以内にリリースできると言えることになる。

ベロシティは、昨日の天気の見積りの目安にするツールである。生産性を計測するものではない。チームによってベロシティの単位に使う基準値は異なる。したがって、ベロシティを使ってチームを比較するのは愚かな行為だ。標準ストーリーポイントなどというものは存在しない。同様に、ベロシティはチームを計測するものであり、個人を計測するものではない。ベロシティを生産性の計測に使えば、アジリティを殺してしまうだろう。

ベロシティは期間の決まったイテレーションで使うものだが、カンバンを使った計画にも同様のアイデアが使える。過去数週間分の作業量から、将来の作業量を推測すればいい。

ベロシティは見積りの便利なツールだ。私が80年代に見た技法よりもはるかに簡単である。だが、あらゆる見積り技法と同様に、使い方を誤ることもある。常に見積りの目的を考えなければいけない。

参考文献

アジャイル開発に関するほとんどの書籍は、計画づくりのところでベロシティについて触れている。ケント・ベックと私が書いた上品な緑の本では、ベロシティの初期の考え方について詳しく説明している。ThoughtWorksの見積りに関するebookでは、ベロシティをストーリーポイントやストーリーカウンティングと一緒に使う方法を説明している。

XPの計画づくりに関する我々の最初の説明については、今もWikiで読めるようになっている。

最初のバージョン（2004-05-10）

XPのベロシティが何なのか分からなくなっている人を何人か見かけたところだ。なので、XPにおいてベロシティが何を指しているのか、改めて明言しておきたくなった。

ベロシティとは、いちイテレーションのなかでチームが（個人のベロシティを表すのであれば、ひとりが）どれだけの成果を成し遂げたかを表すものである。そのベロシティの単位は、何らかの努力単位を使ったものでなければならない。中には人週のような単位を好むものもいるが、理想時間であればそれでも問題ないだろう。だが、それを見積もりに使うのであれば、それは適切ではない。Ron Jeffriesは「グミベア(gummi bears)」という新しい単位を作り、この便宜上の単位を表した。まじめな人はこれを「ストーリーポイント」と呼ぶ。私は、Josh Kerievskyの「NUTs (混沌とした時間の単位）」という言葉が好きだ。

ベロシティは「昨日の天気の原則」に従って計測する。 昨日の天気の原則では、次のイテレーションのベロシティは、最後に行ったイテレーションで実際に出たベロシティに等しいものとする（短期の移動平均値を使うチームもある）。

ベロシティを見積もる時には、15 NUTs のようにきちんと単位を使っているかどうか注意したほうがいい。もし、0.7のベロシティだ、とかなんとか言ってたら、それはおそらく負荷率のことを指している。間違っているから、気をつけろ（負荷率とは、カレンダー時間に対する理想時間の割合。現在はほとんど使われない）。