tfs - Scrum 框架中故事点的度量尺度

Question

关闭。这个问题需要更多focused .它目前不接受答案。












想改善这个问题吗？更新问题，使其仅关注一个问题 editing this post .

4年前关闭。




Improve this question




根据这个Scrum article :

Story points are relative values that do not translate directly into a specific number of hours. Instead, story points help a team quantify the general size of the user story. These relative estimates are less precise so that they require less effort to determine, and they hold up better over time. By estimating in story points, your team will provide the general size of the user stories now and develop the more detailed estimation of hours of work later, when team members are about to implement the user stories.

任何人都可以澄清:

故事点的衡量尺度应该是什么？它应该是 10、100 还是给定产品待办列表中分配的最高故事点？

(有点跑题)“产品待办事项”(查看附图)由项目的所有用户故事组成，而冲刺待办事项包含产品待办事项中故事的子集。话说回来;如果一个产品待办列表就足够了，那么为什么 TFS 允许我们有多个产品待办列表项？

Answer 1

您可以使用任何您喜欢的比例。我倾向于做的是斐波那契 (1, 2, 3, 5, 8, 13, 21, ...)。为了设置比例的基线，我们采用了一个黄金故事，它是平均大小，并用 8 和一个稍微小一点的故事来估价 5。我们现在只将所有其他故事的值(value)都放在这两个故事上。而且由于您使用敏捷，您只是在不断改进。所以如果你觉得你需要有不同的黄金故事:那就去做吧。

PBI(产品待办列表项)工作项不是产品待办列表本身。这是积压的故事。产品待办事项列表列出了您希望在某个时间按特定顺序实现的所有故事(希望业务值(value)最高的故事排在最前面)。当您想将故事拉入冲刺时，您可以更改迭代路径。现在它已从产品待办列表中拉出并显示在冲刺待办列表中。