アジャイリストのコミュニティで，ストーリポイントとベロシティの利用が議論されている。見積や全体進捗を把握する手段としてこれらを用いることに対して，皆が疑問を感じ始めているのだ。基本的な認識として共通しているのは，これらの指標が乱用されることはあっても，効果的に利用されることはほとんどないという事実である。
Joshua Kerievsky氏はストーリポイントを自身が使用した経験から，それがいかに乱用されているかを詳細に報告している。ストーリポイントの効果が不合理に誇張された例として氏が紹介しているのは，次のような話だ。
2004年のある日，Jimはチームに対して，もっと開発速度を上げるように求めました。そのチームはそれまで，イテレーション毎に平均52ポイント程度のベロシティを持っていました。数ポイントの振れはあったものの，値としては概ね安定したものでした。ところがJimが"スプリント"を求めたわずか数週間後，チームのベロシティが80台にまでジャンプアップしたのです！
いったい何が起こったのか，私はあるメンバに聞いてみました。
すると彼女はおかしそうな目で私を見て，"最近ここでは，くしゃみをしてもストーリポイントが付くんですよ" と言ったのです。私はチームのしたたかさに驚き，そして呆れました。このチームは２人の素晴らしい企業倫理コーチが指導していました。訓練を受け，評価されていたのです。彼らが開発速度を向上させて見せたように，ストーリポイントの評価値をいきなり膨らませることは，私自身にも可能です。
この経験以降，私のストーリポイントとベロシティに対する信頼感は薄れ始めました。
氏はさらに，ポイントでチームを比較するという行為がいかにアンチパターンであるかを強調している。
ここ何年もの間，私は複数の会社の何人ものマネージャから，”Xチームはスプリントごとに24ストーリポイントを上げているのに，Yチームが12ストーリポイントなのはなぜだろう?" というような質問を受けています。"チームの規模はほとんど同じなのに，こんなに差があるのはなぜなのか？"というのです。
このような質問をするマネージャたちは，ベロシティをチーム固有の能力指標ではなく，パフォーマンスの測定値として解釈するという，言わば思考の罠に陥っているのです。
Uncle Bob Martin氏もまた，ブログへの自身のコメントでこれを認めている。
ストーリポイントに苦労しているチームは少なくありません。プロジェクトマネージャがただ開発速度を上げるように求めるだけで，何もせずに成果を得ようとするようなチームでは，ストーリポイントに何の価値もないことは明らかです。能力以上の成果を求めるマネージャを満足させるために，ベロシティチャートを偽っているチームさえあるのです。このようなチームには，他のアプローチの方が相応しいのかも知れません。
Scrum Alliance グループで先日展開されたEメールスレッドでは，Ron Jeffries氏がベロシティの測定指標としての価値を批判していた。
- ベロシティは多くの場合，誤用される。
- ベロシティは多くの場合，改ざんされる。
そしてもっとも問題なのは，ベロシティが必要以上に重要視されている，ということです。アジャイルで重要なのは，実行と延期の選択にるプロジェクトの運営であって，コスト問題を解決や改善することではありません。
ベロシティを重視するようなチームは，仕事の価値を認めていないのです。もし私だったら，ベロシティなどというものを考え出すことはなかったと思います。
氏はそのスレッドで，さらに詳しく説明している。
ここでの質問の大半が，進捗評価を改善してもっと正確にするにはどうすればよいか，という内容です。さらに詳しく見て行くと，作業の終了時期を先に設定して，すべてを完了するようにチームメンバをプッシュしているようなチームの存在が分かってきます。正確な指標を欲しがるのは，そういったチームなのでしょう。
プロダクトオーナの中には，管理作業をほとんど，あるいはまったく行わないで，すべてバックログに回してしまう，つまり”計画に従う"だけの人もいるのです。
プロダクトオーナがバックログをクリエイティブに利用して，可能な限り最高の製品を提供してこそ，スクラムはその効果を最大限に発揮します。進捗管理に力を入れてみたところで，大してその役には立ちません。
Mike Cohn氏は先日，進捗管理こそ重要だと考えるユーザとの会話を想定した記事をブログに書いた。そこでのユーザの言い分は，
まず何といっても，将来の資金調達を考えるためには，今回のターンで進捗管理のプロセスがどの程度正確なのかを知っておく必要がある。関係者にもっと資金を出してもらうように頼むとき，最初に約束した1/2しか達成できてないなければ，彼らはあたかも金をブラックホールに投げ込んでいるように感じるはずだ。だからそれを管理するためにも，もっと高度な進捗評価を実現できる，合理的なアプローチを用意しておかなくてはならない，それがひとつ。もうひとつは，資金を調達する(これには相当なリードタイムが必要だ)ためには，大体いくら程度必要なのかを前もって知る必要がある，ということだ。見積が正確と言うには程遠いものなら，その精度を上げなければならない。それを持って，私は資金を得るために駆けずり回ることになるのだから。とは言っても，ただで金が手に入るはずがない。プロジェクトの完了に至るまで，全体の状況を把握するような，さまざまなレベルの指標がなければならない。要するに，プロジェクトのバーンダウンに至るまで，全体を通じたコスト監視を行うことが必要なのだ。
Vasco Duarte氏はストーリポイントを置き換える案として，ストーリ数による計測を提案している。
プロジェクト進捗の予実状況を長期的 (これを忘れないでください – 以下のことが当てはまるのは，例えば今後３スプリントといった長さの期間に限られます) に監視する場合には，すべてのストーリが同じサイズである，という仮定が成立します。したがってスプリント単位で完了した項目数を数えれば，進捗を把握することが可能なのです。
Mike Cohn氏がコメントで述べているのも，これと同じような意見だ。
かんばん方式のチームが明示的な見積を行わないというのは，私もそう思います。その根拠としてしばしば指摘されるのが，すべての作業は同じサイズであるという，彼らの暗黙的な推測です。
Neil Killick氏が提案するのは，進捗評価を必要としない別アプローチの資金管理だ。そこで氏は，自身が行ったウェブサイト開発での経験の例を対比している。その例では明確に定義された予算範囲内で，ベンダは最高のソリューションを構築する。作業内容に不満ならば，いつでも契約関係を解消することができるというものだ。
このような選択について，氏はこう説明している。
進捗を評価する必要はありません。同意できるならば設計は変更も追加もできますし，改善が期待できる変更は採用されます。私が希望する結果を実現すべく，密接な協力関係を望んでいる会社があります。(契約によって金を失うという)大きなリスクに向き合う用意のできているものは，自分たちの仕事の品質とユーザとの信頼関係に自身を持っているのです。
読者はベロシティやストーリポイントによる評価が，チームの不正な行動を促すような事実に気付いた経験をお持ちだろうか？ コミュニティリーダが示したいくつかの代案に対して，読者の意見を聞かせてほしい。