velocity - 速度是否会影响 Scrum 中的团队承诺

Question

在 sprintplanning 结束时，当提交将在即将到来的 sprint 中完成的工作时，记住速度是一个好主意吗？

例如，当团队想要承诺一些用户故事，估计为 10 个故事点，而平均速度为 7。是否应该调整承诺以更好地匹配速度？

在我看来，帕金森定律似乎即将生效。

为团队隐藏速度数字并仅使用它来估计某个功能/故事何时完成不是更好的主意吗？

Answer 1

在 Sprint 计划的开始而不是结束时牢记速度是一个好主意。

Velocity 是开发团队的指南。例如，如果速度为 15，他们会考虑将故事点总数纳入 Sprint。然而，作为 Sprint 计划的一部分，他们将这些故事分解为任务。只有在这一点上，他们才能清楚地了解他们在即将到来的 sprint 中可以做什么。可能是 10 个故事点，也可能是 20 个故事点。速度只是一个指南。

我还可以补充一点，对开发团队隐藏东西是一个非常糟糕的主意。Scrum 的支柱之一是透明度。

此外，最新版本的 Scrum 指南已经删除了对“承诺”一词的所有引用。我们现在，更准确地说，使用“预测”这个词。

希望有帮助。

Answer 2

这取决于团队的赛道历史和他们在过去几个冲刺中的速度。因此，如果他们已经有一段时间平均得分为 7，那么接受 10 个故事就是让团队失败。

一个小的修正，我们不再使用“承诺”这个词，因为它会被管理层误解，如果团队不履行承诺，他们就会遭受“死亡行军”；尽管他们实现了 sprint 目标的 95%。相反，我们使用预测这个词，因为我们永远无法保证基于不确定性、复杂性和意外事件的成功。

尝试将故事分解成更小的故事，以便团队能够实现它们，但鼓励他们在每个 sprint 中做得更好，并在每个 sprint 中加倍努力。因此，在回顾中，不断地问“我们可以做些什么来改进并做得更多？” 现实团队的感受。

在你的 sprint 计划中，团队是否觉得他们真的可以实现它，如果可以，那就去做吧。如果不是，那么请重新考虑如何处理如此大的故事或将其分解以提供增加价值的增量。

永远不要对团队隐瞒任何事情，Scrum 是关于透明度、开放性和健康的工作环境。如果你开始隐瞒，团队也会开始对你隐瞒。

Answer 3

我们可以将速度作为下一个 sprint 的新故事点的基准，但这不是强制性的，它会影响团队的承诺。每个团队都可以与自己相媲美。我们可以使用速度来比较我们的新故事点，并尝试改进我们自己并加快交付速度。

Answer 4

速度是一个很好的衡量标准，可以根据过去的表现/速度在 Sprint 的跨度内进行预测。Sprint 通常在速度估计中允许缓冲，以便可以考虑不可预见的情况。此缓冲区基于历史数据、即将到来的 PTO 等。

我们可以从基于产品的团队和基于服务的团队的角度来看这个问题。对于产品团队来说，进入 sprint 的需求可能比服务团队更灵活（服务团队可能会处理不太灵活的客户）。

理想情况下，团队在 Backlog Grooming 过程中考虑到速度——这允许 Scrum 团队从 backlog 中提取他们知道应该按时完成的故事。Sprint Planning 是生产团队进一步讨论这些经过修饰/调整大小的用户故事的细微差别的地方，以更好地了解功能需求。