最近のブログVelocity is Killing Agile（VelocityによってAgileは死んでしまうのか？）でオリジナルのAgileマニフェスト宣誓者であるJim Highsmithは生産性の尺度としてVelocityを用いているvelocity-ハングリーなマネージャについて述べている。「．．．彼らはvelocityチームのvelocityやチーム間のvelocityを測定する事にしばしばのめり込み、velocityを組織レベルやさらにはデベロッパー個人（とても良くない）を対象にしています」と氏は書いている。
Highsmith氏はますます生産性を測定するためにvelocityが用いられるようになっていると指摘する。何故かを考えるのは簡単である。あなたにとって何がうまくいっていて、何がうまくいっていないかを特定するために役立つ生産性の尺度は、どれもそれぞれに応じてあなたを調整してくれます。また、velocity情報は簡単に集める事が出来、簡単に計算でき、生産力の尺度として可視化する事が出来ます。しかし、これらの尺度が、提供されるストリーポイントのボリュームに過度にフォーカスしているとHighsmith氏は警告する。「このボリュームは提供される顧客の経験の質を損ねます」
問題を拡大させながら、アジャイルの運動は高いレベルの顧客関係にフォーカスするようになりました。基本的には良い事ですが、我々はひどくやり過ぎてしまいました。多くのアジャイリスト（Agilists）は自分たちが組織を技術的な実践にフォーカスさせることができずできないことに公然と非難しています。しかし、プロダクトマネージャ/オーナーがすべての優先度を決定し、そしてvelocityを用いてパフォーマンスを測定するのを我々が推奨している事がなぜ驚きなのでしょうか？我々は伝統的な手法において顧客へのフォーカスが欠けている事に対して過度に保障しすぎてきました。プロダクトオーナー/マネージャに優先度付けのコントロールを与える事によって。
Highsmith氏はアジャイルの実践においてのvelocityの利用に関して初めて疑問を呈した自分物ではない。昨年投稿された氏のブログアジャイルプロジェクトにおけるVelocityの間違った利用において、Mark Levison氏はvelocityをチームによって完遂され、完遂するまでにかかった時間で分割される仕事の量と定義している。「仕事の量はストーリーポイント（サイズの相対的な尺度）で普通測定される」と氏は述べている。
Levison氏は2つのチームの生産性を比較するためのvelocityの利用に関して述べている。しかし、Levison氏はこうも指摘している。
Agile/Scrumチームは伝統的な絶対的な見積もりに対して、相対的な見積もりを利用しています（例えば、このストーリー/機能が自分たちの標準的なストーリーに対して大きいか小さいか）velocityを比較する事、ベンチマークを取る事、その他の試みの問題は私のストーリーポイント≠あなたのストーリーポイントであるという事です。異なるプロジェクトでは異なるストーリー標準を用いるためです。彼らは異なる問題領域での仕事をしており、異なるメンバーを有しています。
Scott Ambler氏はチーム間でのvelocity比較の危険性について数年前に記事を書いており、むしろそれぞれのチームの加速度の計算を提案していた。Ambler氏は述べているが、計算する事は簡単であるという利点がある一方、自動化する事も可能で、値が操作される事も難しい。下がり気味だが、Ambler氏が「ごまかしの要因」と呼んでいる要因に依存する間接的な尺度である。
Highsmith氏がつけたタイトルは問題をセンセーショナルにしているかもしれないが、氏もLevison氏もvelocityが全く悪であると言っているわけではない。Highsmith 氏は「velocityを適切な利用はキャリブレーションツールになり、キャパシティベースの計画を行う助けになる」と述べている。Levison氏は「Velocityとリリース計画の真の価値は次のリリースの前に何を達成する事が出来るかに関してプロダクトオーナーに良いアイデアを提供できることにある」と述べている。