スクラムフレームワークのストーリーポイントの測定スケール[クローズ]

Question

このスクラム記事：

ストーリーポイントは、直接翻訳されていない相対値です。 特定の時間数。代わりに、ストーリーポイントはチームの定量化を助けます ユーザーストーリーの一般サイズ。これらの相対的な見積もりはそれほど少ない 判断するために労力が少ないように正確であり、彼らは保持しています 時間がかかるストーリーポイントを推定することによって、あなたのチームウィル 今すぐユーザーストーリーの一般的なサイズを提供し、より多くの展開 チームメンバーがあるときの後の仕事の時間の詳細な見積もり ユーザーストーリーを実装しようとしています。

誰もが明確にすることができます：

1. ストーリーポイントの測定規模は何ですか？与えられた製品のバックログに割り当てられた10,100、または最高のストーリーポイントのうち、割り当てられたものであるべきですか？
2. （LITH OFF-TOPIC）「製品バックログ項目」（添付画像を確認してください）プロジェクトのすべてのユーザーストーリーで構成されている間に、Sprint Backlogに製品バックログからのストーリーが含まれています。そうは言っても; 1つの製品バックログが十分である場合、なぜTFSに複数の製品バックログアイテムを持つことができますか？

Answer 1

1. You can use any scale you like. What I tend to do is the Fibbonaci (1, 2, 3, 5, 8, 13, 21, ...). To set the baseline of the scale we took a golden story which was average size and valued that with an 8 and one with a little less size and valued that 5. We now just value all the other stories to those two. And since you are working Agile you are just continuously improving. So if you feel that you need to have different golden stories: just do it.
2. The PBI (Product Backlog Item) work item is not the Product Backlog itself. It is the story on the backlog. The Product backlog list all the stories you would like to implement at some point in a specific order (hopefully the one with the highest business value is on top). When you want to pull a story into a sprint you change the iteration path. It is now pulled off the product backlog and shown on the sprint backlog.