在整个Sprint中完成用户故事时，可以将所需的实际工作量作为指标进行跟踪。在某些情况下，实际工作量将大于或小于原始用户故事点估计值。
在这些情况下，开发人员将要求输入高于或低于原始估计值的数字。
在规划期间，团队使用用户故事点量表（Fibonacci或类似物）来衡量每个用户素材的工作量。常用的估算方法包括2（1,2,4,8），斐波纳契数列（1,2,3,5,8等）或类似的幂。
这种量表的目的是反映与估算任务需要多少努力相关的不确定性水平，因为任务变得更大。例如，对于一项小任务，例如阅读电子邮件，您可以非常准确地估计您需要多长时间阅读它;不确定性的程度很小。但随着任务规模的增加，即回复50封不同的电子邮件，要确切知道需要多少努力就更难了;您估算的不确定性水平将呈指数级增长。
我一直在阅读和浏览一段时间，试图回答以下问题但没有取得多大成功：
完成用户故事后，所需的实际工作量与原始估算值不同。由于现在不确定性已经消失，实际工作量是否应反映用户故事点量表中的值？或者，另一方面，是否可以自由使用更准确的值？现在，实现者确切地知道他需要多少努力来完成用户故事。
我的理由是，通过跟踪实际工作的数据比规模（斐波那契或其他人）提供的更准确，团队将获得更准确的指标，以后会影响他们在中/长期的速度术语。
答案 0 :(得分：3)
故事点是完成故事所需的相对努力的任意度量。它们的用处在于它们可以提供速度，而速度又可以作为指导未来短跑的工作量。
当一个团队估计一个故事时，他们没有考虑完成工作所需的小时数或天数。相反，它们与他们过去所做的故事相比较。这种比较包括诸如感知复杂性，他们对所涉及的技术的经验以及测试困难等因素。在许多情况下，团队会增加他们提供故事的分数，因为他们认为这是有风险的。
现在考虑以下示例。
一个团队调整的故事大小与他们过去做过的几十个类似故事非常相似。他们给了3分。但是当他们进行开发时，他们发现有一个意想不到的问题导致需要比预期更多的时间和精力。工作完成后，他们将故事大小调整为8分。
在同一个冲刺中，团队的大小与上面提到的类似。他们也给了3分。这一次，开发人员意识到他们几年前已经编写了一些相同的代码。他们恢复旧代码，故事在几分钟内完成。他们将故事重新调整为1分。
在下一个冲刺中，类似的故事再次发生。他们应该给出多少故事点？ 1还是8？
故事大小调整是衡量故事的感知大小。有时会有变化。在工作完成后通过重新调整大小来获得任何价值是值得怀疑的。但是，你应该做的是谈论你的回顾中的变化。也许团队需要更好地审视故事的风险？也许在进行估算之前需要更好地检查现有代码？
答案 1 :(得分：0)
在sprint中无法更改用户故事的估计。
所有这些差异都是学习。当这些差异发生时，我们应该作为一个团队进行改进。
这一切都在于检查＆amp;也适应估计。在3-5次冲刺之后，团队的估计和准确性会更加准确。也将提高他们的速度。