標準ストーリーポイント

最近いくつかリクエストをいただき、エクストリームプログラミングの計画アプローチを利用する複数のチームで標準のストーリーポイントメカニズムを考案しました。エクストリームプログラミングでは、同じストーリーポイントを使用して、同じストーリーポイントがどのチームも利用できるようになるという期待があります。たとえば、チームAが3ストーリーポイントを費やせば、チームBも同様に3ストーリーポイントを費やすということになります。

これを実現しても限定的な価値があり、最悪の場合は危険だと私は考えています。

エクストリームプログラミングの見積もりシステムは、XpVelocity と YesterdaysWeather に基づいています。この場合、見積もりを行うとき、見積もり單位そのものは重要ではなく、大まかな比較値で見積もり、YesterdaysWeather をキャリブレーションに利用することが重要になります。

この状況では、ストーリーポイントは Yestrday's Weather が提供するフィードバックループのアンカーとしての機能を果たすだけです。ストーリーポイントには、チームのタスクの性質、チームの能力、チームの見積もりが楽観的か悲観的かなどのさまざまな仮説が組み込まれています。チーム間で標準を策定しようとすると、これらの要因をすべて標準化する必要があります。これは私にとっては非常に難しいことのように聞こえますし、これを効果的に行っている人は他にいないと思います。不可能という意味ではありません。単に難しいということです。

その標準単位をチーム全体で利用すれば、必然的に誰かがチームのパフォーマンスを比較するようになるので、それが危険な面での要素となります。誰もがチーム間の測定に使用しないことを誓ったとしても、将来的にそれが発生する可能性は常にあります。これにより、チームは測定を歪めて、ストーリーポイントがより多く達成されているように見せかける可能性があります。私の懸念は、これによって昨日の天気のフィードバックループが断ち切られ、計画プロセスが狂ってしまう可能性があるということです。生産性を測定する方法があれば非常に貴重なものになるはずですが、ソフトウェアの性質上、私たちは CannotMeasureProductivity という問題があると私は常々懸念しています。

つまり、試してみる価値があるためには、何らかの貴重なメリットをもたらす必要があります。しかし、私には何も見えません。私は、チームへの移行と見積もりの迅速化に役立つという理由を聞きましたが、問題と現在のコードベースがある程度精通するまでは、新しいチームで見積もりを行うことはできません。それを行うと、チーム内のストーリーポイントの相対的なサイズも把握できます。Thoughtworks 内のプロジェクト間でメンバーを移動させますが、ストーリーポイントの違いによる新規チームへの移行における見積もりに関する困難については、これまで苦情を聞いたことはありません。

2012年5月10日に再投稿