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

Question

根据这篇Scrum文章:

故事点是相对值,不会直接转换为特定的小时数.相反,故事点可以帮助团队量化用户故事的总体大小.这些相对估计不太精确,因此它们需要较少的努力来确定,并且随着时间的推移它们会保持更好的状态.通过估算故事点,您的团队现在将提供用户故事的一般大小,并在团队成员即将实施用户故事后,开发更详细的工作小时数估算.

任何人都可以澄清:

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积压中.