让我们举个例子，假设我们有 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 周的 sprint。这是 14 天的时间大小=5,14x5=70 个工作日。现在值 10 是什么意思？这是否意味着团队应该花费的时间（小时或天）？什么是故事点？假设这是第一个冲刺；当你没有最后一个 sprint 的速度时，你将如何估计 sprint 的数量？
啊！适合我从记忆中写作。
故事点当然与估计有关，当您试图弄清楚您可以为 sprint 做多少事情时，故事点是实现部分或整个功能所需的一个“工作”单元。一个故事点可能是一天，也可能是一个小时，或者介于两者之间。我混淆了下面的“估计”和“故事点”，不知道我在想什么。
我最初写的是“估计”和“故事点”。我打算写（并在下面编辑）是“故事点”和“速度”。
故事点和速度齐头并进，它们一起工作，试图让你感觉到“我们在给定的时间内可以完成多少”。
让我们举个例子。
假设您想以小时为单位估计特征，因此估计为 4 的特征将需要 4 小时才能完成，由一个人完成，因此您将这样的估计分配给所有特征。因此，在争夺资源时，您认为该功能或其“故事”值 4 分。
现在假设您的项目有 4 个人，每个人每周正常工作 40 小时，但是由于他们周围发生的其他事情，例如支持、与营销人员交谈、会议等，每个人将只能将 75% 用于实际功能，另外 25% 将用于其他任务。
因此，每个人每周有 30 小时可用，如果算上所有 4 个人，则该周总共有 30*4 = 120 小时。
现在假设您正在尝试创建一个 3 周的 sprint，这意味着您可以完成 3*120 小时的工作。这是你的速度，你移动的速度，你可以完成多少“故事点”。
您的速度单位必须与您的故事点的单位兼容。您无法用“我们有多少小时可用”来衡量“开发人员在实现此功能时将消耗多少杯”。
然后，您尝试找到一组功能，它们加起来接近但不超过 120 分，按优先级排序。这将只是从顶部和向下累积累积，直到您完成一项使总和超过或等于这 120 点的任务。如果它翻倒了，请不要包含该任务。
您可以轻松地估算几天或开发人员消耗的咖啡杯数，就像数字代表您正在做的工作类型一样，它可以与您将执行的实际工作相关（即如何你有很多时间）。
您还应该在每个 sprint 之后评估您的工作量，以确定 75% 的数字是否准确。例如，如果您只完成了计划的一半，请确定您的功能估计是否错误，或者您的工作量估计是否错误。然后在估算和规划接下来的 sprint 时，将您学到的知识考虑在内。
另请注意，如果功能变得太大，则应将其拆分。造成这种情况的主要原因是，更大的估计值具有更多的不确定性，您可以通过将其分解为子特征并进行估计来减轻这种不确定性。然后，大的整体特征成为所有子特征的总和。它还可能使您能够通过将不同的子功能分配给不同的人来将功能拆分给几个人。
一个好的经验法则是，估计超过 1 天的特征可能应该被拆分。*
请记住，积分只是通过使用“计划扑克”作为一种常见做法而建立的 ROM（大致数量级）。前几个 Sprint 是当您开始确定积分对团队的意义时，您进行的时间越长，团队获得的准确度就越高。
另外，还要注意使用间距更大的点。我见过并使用过的一种做法是使用斐波那契数列，它确保你没有太多的 1 点差异。
也不要忘记测试人员，在指出一个故事时，任何进行测试的人都需要权衡，因为有时一个简单的开发任务可能会导致大量的测试工作，如果他们是真正的 Sprint，其想法是完成所有事情，因为它可以交付（构建，测试和记录）。所以一个故事的估计是由团队而不是个人决定的。
值 10 只是相对于其他估计值的一个值，例如，它是 20 的一半或比 9 稍微困难一些。没有具体的翻译 1 点 = x 小时的努力是需要指出的.
在我工作的地方，我们有我们所谓的“史诗点”，即一些高级故事的难度，例如将搜索集成到一个新网站中，该网站将包含多个要完成的故事，然后我们估计每个故事的创建时间从分解每个史诗，例如，只需在网站上搜索支持文档。“史诗点”分布在斐波那契数（1,2,3,5,8,13,21,28,35）的变体中，因此更广泛、更模糊的史诗只会获得较大的值，例如大于 8 的任何值, 是一个指标，表明它可以分解成更容易估计的故事。在这里还值得注意的是，在我工作的地方，我们每周只工作 5 天，在每个 sprint 中，一天都浪费在诸如演示、迭代计划会议、回顾和审查之类的会议上，所以一个 sprint 只有 9 天。
前几个冲刺是值开始变得更加具体的地方，因为根据获得的经验，在如何猜测值方面估计会变得更加清晰。
对于一个新的团队或项目，我们总是从假设一个故事点是一个单一的“理想日”开始，我们计算每个开发人员每周获得大约 3.5 个理想日，这就是我们计算可能的初始速度的方式。
一旦你经历了“计划扑克”阶段并平衡/比较了你所有的故事，一个故事点的实际真实世界持续时间真的是未知的——你真正拥有的只是相对持续时间的一个很好的想法，并使用你的得出可能的速度的最佳判断。
至少，我是这样做的！
如果您还希望您的故事点大致等于理想的一天，那么我建议您将您的故事分解为更小的故事，否则您将不会有好的时间来规划和跟踪迭代。
到处都是很好的答案。
我想补充的一点是，您选择什么作为积分值的基础并不重要（小时、理想天数等）。重要的是保持一致。
如果您确实保持一致，它将允许您发现团队的“真实速度”。例如，假设您的迭代次数很少：
iteration 1 = 120 points
iteration 2 = 95 points
iteration 3 = 115 points
现在您正在开始第 4 次迭代，并且您在 backlog 中有以下内容（按优先级排序）：
item 1 = 50 points
item 2 = 30 points
item 3 = 30 points
item 4 = 40 points
现在假设您的分数估计是一致的，您可以合理地确定团队将完成项目 1,2 并且可能完成 3 但绝对不会完成 4。
您可以将其应用于发布积压工作，以改进您对发布日期的预测。这就是让 Scrum 团队在进行过程中改进他们的估计的原因。
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