ストーリーポイントを使用して、複数のチームによって見積もられた複数のプロジェクトのサイズを説明できますか？
KLOCは、いくつかのプロジェクトを比較すると、サイズを表現するには不正確すぎると批判されてきました。
1つのソースで、ストーリーポイントを使用する計算を見つけたため、100SPあたりのバグ数に関して小規模/大規模プロジェクトを比較できます。
すべてのチームが共通の定義/参照ストーリーを持っているとすると、この意味でストーリーポイントを使用することを妨げる何かが欠けていますか？つまり、チームの生産性はさまざまであると理解していますが、「量」の見積もり（相対的な労力の観点から）はそれほど変わらないはずだと私は考えています。私には、KLOCよりもはるかに優れているように見えます。
ストーリーポイントは「十分に良い」測定値です。つまり、これらを使用して、他の作業ブロックと比較した作業ブロックのサイズを概算できます。そのため、nストーリーポイントあたりのXの測定は、本質的に不正確になります。ただし、ほとんどの目的にはおそらく「十分」です。
チーム間で比較するという問題は別としても、この測定では、特定の努力によって欠陥密度が増加または減少した場合の傾向を示すことができます。あなたの目標が欠陥密度を減らすことであり、チームがこの分野で進歩を遂げようとするために回顧展で行動を特定する場合、この測定基準は価値があります。
したがって、チーム間で欠陥密度を比較する限り、考慮すべき2つのことがあります。まず、チーム間で比較することがなぜ役立つのでしょうか。あるチームが別のチームと大幅に異なる場合、あなたは何を変えますか？または他とは少し異なりますか？これに対する答えは、メトリックにどの程度信頼できるかを示します。
このメトリックを適用し、チームAの欠陥率が100ストーリーポイントあたり20欠陥であるとします。チームBのレートは100ストーリーポイントあたり2です。おそらく、これらのチームのストーリーポイントのスケールは、同じストーリーを伝えないほど異なることはできません。チームBのプロセスでは、チームAよりもはるかに少ない欠陥が作成されます。チームBには100SPあたり9つの欠陥がありますが、これもほぼ同じです。 SPのスケールが異なっていても、効果的に正規化できれば、数値は7と10になりますが、それでも同じ話です。ほぼ同じです。
それで、あなたが区別をすることをあなたに要求する何かを測定しようとしていたとしましょう。これは問題になるでしょう。その理由は、共通のリファレンスストーリーを持つことはほぼ不可能だからです。参照ストーリーが機能するのは、チームが以前に作業を行い、その作業を行うために必要なことをよく知っているためです。次に、その作業に関連する他のストーリーを推測します。共通のリファレンスストーリーを作成するには、すべてのチームのメンバーが関与しているものが必要です。特に大きなストーリーを持つ2つのチームでそれを取得できるかもしれませんが、それは実際的ではありません。さらに、見つけたとしても、チームの将来の仕事についての推測が一致していると信じる理由はありません。チーム間でポイントを正規化する必要がある精度と精度が必要な場合、ストーリーポイントは適切な測定値ではありません。
妥当と思われるストーリーポイントサイズの一般的な参照を想定しています。ただし、一般的にストーリーポイントはチームごとの概念であり、そのようなチーム間で使用することはできません。