tfs - 在 Scrum 框架中测量故事点的规模

Question

根据这篇Scrum 文章：

故事点是不直接转化为特定小时数的相对值。相反，故事点有助于团队量化用户故事的总体规模。这些相对估计不太精确，因此它们需要更少的努力来确定，并且随着时间的推移它们保持得更好。通过估计故事点，您的团队现在将提供用户故事的一般规模，并在团队成员即将实施用户故事时制定更详细的工作时间估算。

谁能澄清一下：

1. 故事点的衡量标准应该是什么？它应该是 10 个、100 个还是给定产品 backlog 中分配的最高故事点？
2. （有点离题）“产品待办事项”（查看附件图片）由项目的所有用户故事组成，而冲刺待办事项包含产品待办事项中的故事子集。话说回来; 如果一个产品 backlog 就足够了，那么为什么 TFS 允许我们拥有多个产品 backlog 项目？

Answer 1

1. 你可以使用任何你喜欢的比例。我倾向于做的是斐波那契 (1, 2, 3, 5, 8, 13, 21, ...)。为了设置规模的基线，我们采用了一个平均大小的黄金故事，并用 8 来评价它，而一个较小的故事则用 5 来评价。我们现在只评价这两个故事的所有其他故事。而且，由于您正在敏捷工作，因此您只是在不断改进。所以如果你觉得你需要有不同的黄金故事：那就去做吧。
2. PBI（产品待办事项）工作项不是产品待办事项本身。这是积压的故事。Product backlog 列出了您希望在某个特定时间点按特定顺序实施的所有故事（希望具有最高业务价值的故事排在首位）。当您想将一个故事拉入一个 sprint 时，您需要更改迭代路径。它现在已从产品 backlog 中删除并显示在 sprint backlog 中。