如何在 Scrum 中测量估算点和故事点？ [关闭]

Question

举个例子，假设我们有 5 个故事 A、B 和 C、D、E。

Importance Name Estimate
90         B 
70         A 
50         C 
35         E
10         D 

故事是根据它们的重要性（优先级）排序的。你如何估计它们？是根据特征的大小来估计的吗？例如，我给了他们估计值：

Importance Name Estimate
90         B     10
70         A     12 
50         C     9
35         E     20  
10         D     11

假设这是一个为期 2 周的冲刺。这是 14 天的时间大小=5,14x5=70 个工作日。 现在值 10 是什么意思？这是否意味着团队应该花费的时间（小时或天）？什么是故事点？假设这是第一个冲刺；如果没有最后一个 sprint 的速度，您将如何估计 sprint 的数量？

Answer 1

啊！适合我凭记忆写作。

故事点与课程的估计有关，当您试图弄清楚您可以为 sprint 做多少事情时，故事点是实现部分或全部功能所需的一个“工作”单元。一个故事点可能是一天，也可能是一个小时，或者介于两者之间。我混淆了下面的“估计”和“故事点”，不知道我在想什么。

我最初写的是“估计”和“故事点”。我打算写（并在下面编辑）是“故事点”和“速度”。

---

故事点数和速度齐头并进，它们共同作用，试图让您了解“我们在给定的时间内可以完成多少”。

举个例子吧。

假设您想以小时为单位估算特征，因此估算值为 4 的特征将需要 4 小时才能完成，由一个人完成，因此您将这样的估算值分配给所有特征。因此，在争夺资源时，您认为该功能或其“故事”值 4 分。

现在假设您的项目有 4 个人，每个人正常每周工作 40 小时，但是由于他们周围发生的其他事情，例如支持、与营销人员交谈、会议等，每个人只会能够在实际功能上工作 75%，另外 25% 将用于其他任务。

因此，每个人每周有 30 小时可用，如果算上所有 4 个人，这周总共有 30*4 = 120 小时。

现在假设您要创建一个 3 周的 sprint，这意味着您可以完成 3*120 小时的工作。这是你的速度，你移动的速度，你可以完成多少“故事点”。

速度单位必须与故事点的单位兼容。您无法用“我们有多少小时可用”来衡量“开发人员在实现此功能时将消耗多少杯”。

然后，您尝试找到一组功能，它们加起来接近但不超过 120 分，按优先级排序。这将只是从顶部和向下累积累积，直到您完成一项使总和超过或等于这 120 点的任务。如果它翻倒了，请不要包含该任务。

您可以轻松估算开发人员消耗的天数或咖啡杯数，就像数字代表您正在做的工作类型一样，它可以与您将执行的实际工作相关（即，您有多少时间可用）。

您还应该在每个 sprint 之后评估您的工作量，以确定 75% 的数字是否准确。例如，如果您只完成了计划的一半，请确定您的功能估计是否错误，或者您的工作量估计是否错误。然后在估算和规划接下来的 sprint 时，将您学到的知识考虑在内。

另请注意，如果功能变得太大，则应将其拆分。造成这种情况的主要原因是，更大的估计值具有更多的不确定性，您可以通过将其分解为子特征并进行估计来减轻这种不确定性。然后，大的整体特征成为所有子特征的总和。它还可能使您能够通过将不同的子功能分配给不同的人来将功能拆分给几个人。

一个好的经验法则是，估计超过 1 天的特征可能应该被拆分。*

Answer 2

请记住，积分只是通过使用“Planning Poker”作为常见做法而建立的 ROM（大致数量级）。前几个 Sprint 是当您开始确定积分对团队的意义时，您进行的时间越长，团队获得的准确度就越高。

另外希望使用间隔更大的点。我见过并使用过的一种做法是使用fibonacci 序列，它确保您没有太多的 1 点差异。

另外不要忘记测试人员，在指出一个故事时，任何进行测试的人都需要权衡，因为有时一个简单的开发任务可能会导致大量的测试工作，如果他们是真的 Sprint 的想法是尽可能完成所有事情发货（构建、测试和记录）。所以一个故事的估计是由团队而不是个人决定的。

Answer 3

值 10 只是相对于其他估计值的值，例如它是 20 分的一半，或者比 9 分略难一些。没有具体的 1 分翻译 = x 小时的努力是需要指出的。

在我工作的地方，我们有所谓的“史诗点”，即一些高水平的故事有多难，例如将搜索集成到一个新网站中，该网站将包含多个要完成的故事，然后我们估计每个故事的小时数，这些故事是通过分解每个史诗而创建的，例如只需在网站上搜索支持文档即可。 “史诗点”分布在斐波那契数（1,2,3,5,8,13,21,28,35）的变体中，因此更广泛、更模糊的史诗只会获得较大的价值，例如任何大于 8 的值都表明它可以分解为更容易估计的故事。在这里还值得注意的是，在我工作的地方，我们每周只工作 5 天，在每个 sprint 中，一天都浪费在诸如演示、迭代计划会议、回顾和审查之类的会议上，所以一个 sprint 只有 9 天。为某些事情添加结对编程、修复错误的时间和其他非项目工作（如支持票），很难说少数开发人员将在冲刺中花费多少小时。

前几个冲刺是值开始变得更加具体的地方，因为根据获得的经验，在如何猜测值方面估计会变得更加清晰。

Answer 4

对于一个新的团队或项目，我们总是从假设一个故事点是一个“理想的一天”开始，我们认为每个开发人员每周获得大约 3.5 个理想的天，这就是我们计算可能的初始速度的方式。

一旦你完成了“计划扑克”阶段并平衡/比较了你所有的故事，一个故事点在现实世界中的实际持续时间真的是未知的——你真正拥有的只是一个很好的想法相对持续时间，并根据您的最佳判断得出可能的速度。

至少，我是这么干的！

如果您还希望您的故事点大致等于理想的一天，那么我建议您将您的故事分解为更小的故事，否则您将无法享受规划和跟踪迭代的美好时光。

Answer 5

很好的答案。

我想补充的一点是，您选择什么作为积分值的基础并不重要（小时、理想天数等）。重要的是要保持一致。

如果您确实保持一致，它将让您发现团队的“真实速度”。 例如，假设您的迭代次数很少：

iteration 1 = 120 points
iteration 2 = 95 points
iteration 3 = 115 points

现在您正在开始第 4 次迭代，并且您在积压工作中有以下内容（按优先级排序）：

item 1 = 50 points
item 2 = 30 points
item 3 = 30 points
item 4 = 40 points

现在假设您的分数估计是一致的，您可以合理地确定团队将完成第 1,2 项，可能会完成第 3 项，但绝对不会完成第 4 项。

您可以将相同的内容应用于发布积压工作，以改进您对发布日期的预测。 这就是让 Scrum 团队在进行过程中改进他们的估计的原因。

Answer 6

JB King 给出了最佳答案，但没有投票，这意味着不正确的信息正在被传播并导致对 scrum 的普遍较差的解释。请在此处查看其中一位设计 Scrum 的人的真实答案：

http://blog.mountaingoatsoftware.com/seeing-how-well-a-teams-story-points-align-from-one-to-eight

请记住，这是关于努力，而不是复杂性。

现在在这里阅读并观看视频：

http://www.agilebok.org/index.php?title=Relative_Sizing_and_Story_Points