测量Scrum框架中故事点的比例

Question

根据Scrum article：

  

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

任何人都可以澄清：

1. 故事点的测量尺度应该是多少？它应该是在给定产品积压中分配的10,100或最高故事点吗？
2. （小偏离主题）“产品积压项目”（检查附加图像）包含项目的所有用户故事，而sprint积压包含产品积压中的故事子集。话说回来;如果一个产品积压足够，那么为什么TFS允许我们有多个产品积压项？

Answer 1

1. 您可以使用任何您喜欢的音阶。我倾向于做的是Fibbonaci（1,2,3,5,8,13,21 ......）。为了设定比例的基线，我们采用了一个平均大小的黄金故事，并且估价为8和一个尺寸略小且价值为5.我们现在只重视所有其他故事。既然你正在使用敏捷，你就会不断改进。所以如果你觉得你需要有不同的金色故事：就这样做。
2. PBI（Product Backlog Item）工作项不是Product Backlog本身。这是积压的故事。产品待办事项列出了您希望在特定订单中的某个时刻实现的所有故事（希望具有最高业务价值的故事位于最前面）。当您想将故事拉入sprint时，您可以更改迭代路径。它现在已从产品待办事项中删除，并显示在sprint backlog上。