最近、ScrumDevelopment Yahoo!グループでは、ベロシティの活用と誤用に関して様々な議論がなされている。Kurt Häusler氏は、ベロシティとその価値について、自らの理解を次のように説明している。
はい、ベロシティは前回のイテレーションで完了したストーリポイントを数えることで計測できます。これが生産性の基準としてふさわしいのか、私にはわかりません。私にとって、ベロシティとは中立的な評価基準であり、次のイテレーションでどれくらいのポイントを達成できるか訓練するためのツールとして使うものです。私にとって、ベロシティの高低は、必ずしも善し悪しではないのです。
それでも、ベロシティは重要なツールです。それが何であり、何のためかを理解していればね。私の知る限り、ベロシティは次のイテレーションを計画するためのものであり、生産性を測るためのものではありません。
これはベロシティの唯一の見方ではないことを、Kurt氏も認めている。Joe Little氏はブログで次のように述べている。
... チームのベロシティを2倍にするとしましょう。それも6か月以内にです。
ベロシティ（各スプリント(Sprint)における完了Done(done-done)のストーリーポイント）を2倍にするには通常、いくつか改善が必要になります。
- 完了（もしくは、好みで完了Done）をもっと明確に定義する。私たちは完了をあいまいにしすぎです。ストーリーに応じて変える必要はあるでしょうが、たいていのソフトウェア開発ストーリーでは、完了は極めて明確である必要があり、また、一貫性を持たせることも可能です。私の意見では、「どんな（既知の）バグもスプリントを逃れられません」。そして、テストには少なくとも、機能テストが含まれていなければなりません。
- ベロシティを計測しなければならない。ベロシティを計測していないチームがたくさんあるということが、私にはまだ信じられません。これ以上は、次の機会にしましょう。とりあえず「出掛けるときは、ベロシティを忘れずに」です。
- 障害に優先順位をつけて、ベロシティが2倍になるまで順番に、障害を取り除いたり減らしていかなければならない。ヒント: 障害を取り除いたり減らすことで、ベロシティがどれくらい高まるかによって優先順位をつけたくなります。こっちで25％、あっちで30％というようにね。やがて、実質増加をベロシティで語るようになるでしょう。
ヒント: 品質を高めて技術的負債を減らすことは、ほとんどの場合、ベロシティを大幅に増加させる重要なポイントとなる。これは単にポイントであるだけではなく、本当に重要なことだ。
Adam Sokra氏は、ベロシティはパフォーマンスの基準としては貧弱であるという点で、Kurt氏の意見に賛同しているのだが、ベロシティの効用は主に、イテレーション計画ではなく長期計画にあると考えている。
ベロシティはパフォーマンスの基準としてはかなり貧弱です。生産性が長期にわたって一定に保たれているかを調べることだけが目的であればね。ベロシティを使って、私たちはこう言ってきました。「前回のイテレーションではXポイントを達成しました。だから、今回のイテレーションでもXポイント程度を達成しなくてはなりません」。しかしながら、私たちの多くは、このようにコミットするのは疑わしいと考えるようになってきています。私たちは単に、各イテレーションで達成できると考えていることをコミットすべきだ、と言われています。
ベロシティは長期計画のために使うのが最善だと思います。数イテレーションにわたってベロシティを計測して、平均（できれば範囲）を見つけるのです。そうすれば、その情報を使って、次のようなことが言えるようになります。1) 現在のバックログを考慮して、あるストーリーのセットを完了するのにどれくらいのイテレーションが必要になりそうか？ 2) 期日Xまでに（例えば、展示会に間に合うよう）、いくつのストーリーポイントを実現できるのか、さらには、優先順位付けされたストーリーのどのセットを納品できるのか？
それに、計画はムダだという考え方をする人たちも増えてきている。
ベロシティを生産性の基準として使うべきだろうか？ イテレーション計画のために使うべきだろうか？ もっと長期のリリース計画にはどうだろうか？ そもそも使うべきなのだろうか、それとも、ムダなプラクティスなのだろうか？