敏捷谜团之一是找到一个经过验证的公式来制定 Scrum 团队速度。 我希望通过确定组织面临的首要问题和适用于大多数组织的解决方案来解决这个难题。
让我们先从问题开始：
团队和组织仍然坚持使用基于时间的估算来估算工作范围。基于时间的估计通常有两个共同点：它们是基于时间的，并且它们是不 正确的。无论您使用固定时间来预测还是宣布一个故事点等于几个小时，这些估计几乎总是失败。人员和团队并不像他们想象的那么了解事情需要多长时间。更不用说，您在 询问Scrum 团队中的 每个人都可能根据他们的技能、以前的经验和可用于解决问题的工具类型而有不同的估计。
换句话说，仅仅因为一个项目需要一定的时间，这并不能决定该项目的大小或范围。 初级开发人员可能需要三到五倍的时间来完成，但是一个架构师可以在很短的时间内轻松完成的工作项目。
当我们将一个数字与估计值联系起来时，它就变成了需要某种验证的项目。任何可以让团队轻松了解他们被要求工作的范围，需求，不涉及数字。我们需要在某个时候得出结论，时间不等于大小，并找到更好的方法。
3 种方法使相对大小调整顺利进行
团队应尽可能保持一致。 团队成员的频繁变动会导致中断并破坏我们的预测能力。
产品待办事项 应清晰明确。保持清洁和清爽。
领导层需要摆脱时代潮流。 虽然冲刺可以而且应该保持基于时间，但这并不意味着每个待办事项都需要使用时间来衡量。 我们需要将我们的重点从基于输出的结果转移到基于结果满意的客户。 这通常发生在完成工作所需的输出很少的情况下。
可以在一本非常酷的漫画书中找到对这些准则的更详细解释：敏捷估算和预测的艺术。计算团队速度的公式实际上非常简单。
首先问一系列问题：
团队以前有没有合作过？
团队合作了多少时间？
是否有一个不同的项目在规模和范围上相似，我们可以使用它来围绕规模较小的待办事项项目建立基线？ 我经常要求团队完成他们在过去六周内所做的工作（三个为期两周的冲刺），而不是预测需要多长时间，而是要求他们记录实际需要多长时间。
接下来，我让他们在不暴露时间的情况下取出相同的物品并将它们放入基于
T 恤尺寸的列中。 数字总是不稳定，我解释说这是意料之中的。 最后，我一起抹去时间，并使用 XS=1、S=2、M=3、L=5 和 XL=8
的量规通过冲刺对积压项目进行排序。 我将卡片放入冲刺对齐的堆栈中。 每个堆栈总数都非常平衡。 这就是团队速度！
理解公式的关键是首先要了解团队中经验最少或经验最丰富的人从哪个项目开始并不重要。目标是将 冲刺 视为一个容器，并在不使用时间的情况下决定容器中可以容纳多少容量。一旦你掌握了这个简单的练习，其余的都会自然而然地落实到位。速度真的很容易弄清楚，一旦你可以直视团队的相对规模，就会产生真正的速度。真的就是这么简单。
基于过去的Sprint轨迹记录平均速度
如前所述，团队不应该为速度添加任何部分完成的工作。只有那些标记为“完成”的用户故事才算数，即使在任务中只剩下一小部分工作要做。
仅基于一个冲刺，速度不是用于进行预测的非常可靠的度量。（但它确实让团队了解他们在单个冲刺中可以承诺的工作量。）让我们跟踪他们进一步冲刺的进度。
现在，新的团队继续从Sprint 1 – 4开始随后的发展，他们第一次冲刺的故事点是第二次38,29，第三次38，第四次39。因此，4次短跑后的速度估计平均值为36，如下图所示：
Scrum速度超过冲刺
这个平均值只有四次冲刺，比我们在一次冲刺后的快照更有用。很容易想象，如果积压已经估计的用户故事，我们可以使用此速度进行预测。我们可以预测团队完成所有工作的速度。我们可以对即将发布的版本中我们能够提供的功能进行有根据的猜测。
速度图表
如果Scrum团队完成了多次冲刺，团队可以通过查看速度报告来预测发布和产品完成日期，并更准确地规划未来的项目。根据报告所示的先前冲刺的速度，您可以实现以下目标：
跟踪您的团队报告的每个sprint完成的工作量。
如果您的团队组成和冲刺持续时间保持不变，请估计您的团队在未来冲刺中可以处理的积压工作量。
基于上面的示例，速度图显示了Scrum团队为完成的4个Sprint的每个sprint报告的完成工作量：
