Scrum Framework中的故事点测量规模[关闭]

Question

根据这个 scrum文章：

故事点是不直接翻译成的相对值 具体的小时数。相反，故事点帮助团队量化 用户故事的一般大小。这些相对估计较少 精确使他们需要更少的努力来确定，并且他们持有 随着时间的推移好。通过估计故事点，您的团队将会 立即提供用户故事的一般大小并开发更多 当团队成员所在时，详细估计工作时间 即将实施用户故事。

任何人都可以澄清：

1. 故事点应该是测量规模？如果它在给定的产品积压中分配的10,100或最高故事点？
2. （小off-topicte）'产品积影项'（检查附加图像）由项目的所有用户故事组成，而Sprint Backlog包含来自产品积压的故事子集。话说回来;如果一个产品积压就足够了，那么为什么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.