在复杂和不确定的环境中，未知的事物比已知的更多。 我们有很多不知道的地方。 我们所知道的随时可能更改。 只有我们取得的成就是已知的（除非我们更喜欢掩盖）。 进展是我们已经完成的事情，而不是计划要做的事情。 我们计划做的假设是需要通过新出现的行动和决策进行验证的假设。 我们根据已知信息制定并逐步更改决策。
在Scrum中，让团队了解他们取得的进步是一个好主意。 在考虑内在的不确定性未来时，这是（几个）参数之一。
从Scrum指南 （Sprint计划）中：
这次会议的输入是产品待办事项列表，最新的产品增量，开发团队在Sprint期间的预计能力以及开发团队的过去表现 。
团队通常将“过去表现”的《 Scrum指南》表示为“速度”。 尽管这不是强制性的概念，但在Scrum中应用它是一种好策略 ，对于许多团队来说，提高自己的自我管理水平甚至很有用。
但是，如果通过旧的工业范式的扭曲视角来管理Scrum，则会出现痛苦的问题。 目的迷失了思想，腐败了。 所产生的仅仅是一种幻觉 。 其中一种情况是，速度成为（工作量和所生产的功能的）量的指标，并根据外部理由（即超出团队界限）进行衡量。
尽管可以使用Scrum来应对任何复杂的挑战，但Scrum最主要地用作复杂产品交付的框架。 对于许多组织而言，其产品和服务的可用性和使用至关重要。 他们之所以采用Scrum，是因为他们需要为实现这一至关重要的目标而采取更加敏捷的行动。 Scrum旨在以可发布版本的产品（称为增量）的形式为这些组织提供敏捷性。 目的是使组织能够在每个Sprint结束之前对市场产生有效影响。 对于高度依赖产品或服务的组织，这是敏捷性的关键特征。
出于这个目的，在Sprint结束时没有可发布的产品版本是没有帮助的。 我们甚至允许我们所做的事情充满未知数。 我们破坏了我们做决定的唯一基础。 我们甚至破坏了我们已经脆弱的决策过程的可靠性。 就实际进度而言，“速度”实际上是零。
面对通过Scrum提高敏捷性的目的，当在整个Sprint中都没有创建可释放的增量时，在Sprint Review上讨论Velocity并没有多大价值。 首先可能要解决更严重的问题。 比测量多少点更重要的挑战。 更不用说完全无用的尝试来标准化，标准化，工业化或均衡整个组织中的速度。
在团队没有有效产生可发布的增量的能力的情况下，此类讨论只不过分散了更严重的问题。 速度成为混淆指标。 完成的定义为检查和调整提供了真正的透明性。 “完成”的定义显示了提高产品质量直至可释放的增量所缺少的东西。 面对敏捷性的紧迫性， 定义为“完成”的问题比记录所产生的不可释放的工作量更为重要。
显然，您可以测量创建未完成作品的速度，并且在创建更多未完成作品时更具可预测性。 它不会帮助您在提高敏捷性和产生影响方面取得进展。
相反，在“ Sprint评论”中问自己“我们对市场有何影响？ 我们的上市能力是什么？” 它不仅可以报告完成了多少任务，还可以将对话引导到截然不同的方向。 将调查结果带到您的Sprint回顾展，以找出需要做些什么来改善下一个Sprint上市的可能性。 有雄心勃勃的回顾之旅，而不是漫无目的的乐趣。 希望在下一个Sprint结束之前，开始产生具有可证明的影响力的有价值的增量。 团队外部的任何人都不会再在乎您的Velocity，因为它是进度的外部指标。
面对通过Scrum提高敏捷性的目的，Velocity 实际上只有在不迟于Sprint结束时衡量团队创造可发布产品增量的能力时才有意义。
翻译自: https://www.javacodegeeks.com/2019/05/velocity-scrum-actually.html