完成したユーザーストーリーを使用して将来のユーザーストーリーを推定する
スクラム/アジャイルでは、ユーザーストーリーの複雑さはストーリーポイントで見積もることができます。いくつかのユーザーストーリーを完了した後、プログラマーまたはプログラマーのチームは、それらの経験を使用して、将来のユーザーストーリーを完了するのにかかる可能性のある時間をより正確に見積もることができます。
ユーザーストーリーの複雑さを定量化可能な属性または定量化可能な属性に分解する方法はありますか？
たとえば、User Story XにはGUIに豊富な新しいビューが必要ですが、User Story Xは、サーバー上の既存のビジネスロジックを使用してその機能のほとんどを実行できます。 1から10のスケールで、ユーザーストーリーXの複雑さはクライアントで7、サーバーで2です。ユーザーストーリーXが完了した後、誰かがユーザーストーリーYを完了するのにどれくらいの時間がかかるかを尋ねます。ユーザーストーリーYは、クライアントで3、サーバーで6の複雑さを持っています。ユーザーストーリーXを完了するのにかかった時間を見て、ユーザーストーリーYを完了するのにかかる可能性のある時間を知識に基づいて見積もることができます。
私は他のいくつかの詳細を想像することができます：
- 1つの属性の複雑さ（クライアントの複雑さなど）には、シーケンスのステップ数、ファンクションポイントなどのサブ属性が含まれる場合があります。
- プログラマーがシステムに精通していることや、関連するコンポーネント/インターフェースの数など、考慮できる他のいくつかの属性
- これらの属性は、ある種のユーザーストーリーチェックリストに蓄積される可能性があります。
繰り返しますが：ユーザーストーリーの複雑さを属性/サブ属性の複雑さに分解するための既存の方法論はありますかまたは完成したユーザーストーリーを、より非公式なプロセスの将来のユーザーストーリーを推定する際の指標として使用しています？
私の経験では、それは非常に非公式です。チームがかなり経験を積んでいる場合は、ストーリーを見て、別のストーリーとほぼ同じ労力が必要か、それともかなり多いか、かなり少ないかを判断できるはずです。ストーリーポイントは概算にすぎないため、ある程度一貫して判断を下す限り、正確さはそれほど重要ではありません。
> use (those) experiences to better estimate how much time
> it might take to complete a future user story.
Function_point_analysis fpa はuserstoriesに基づいていませんが、十分な経験があれば推定すると役立つ場合があります。
Fpaの「属性」または次元は、出力、照会、入力、内部ファイル、および外部インターフェースです。