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

Question

在sprintplanning结束时，如果想要在即将到来的冲刺中完成工作，那么记住速度是一个好主意吗？

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

对我来说似乎Parkinson's law即将罢工。

为团队隐藏速度数并不是一个更好的主意，只能用它来估算某个时间/故事何时完成？

Answer 1

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

Velocity是开发团队的指南。例如，速度为15时，他们会考虑将故事点的总数变为Sprint。但是，作为Sprint Planning的一部分，他们将这些故事分解为任务。只有在这一点上，他们才能清楚地了解他们在即将到来的冲刺中能做些什么。它可能是10个故事点，可能是20个故事点。速度只是一个指南。

我是否还可以添加隐藏开发团队的东西是一个非常糟糕的主意。 Scrum的支柱之一是透明度。

此外，Scrum指南的最新版本已经放弃了对“承诺”一词的所有提及。我们现在更准确地使用“预测”一词。

希望有所帮助。

Answer 2

这取决于团队的跟踪历史及其在过去几次冲刺中的速度。因此，如果他们已经平均7分钟，那么接受10个故事就会让团队失败。

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

尝试将故事细分为较小的故事，以便团队可以实现它们，但是鼓励他们在每个sprint中做得更好，并在每个sprint中更加努力。因此，在回顾展中，不断询问“我们可以做些什么来改善并做更多事情？”务实团队的感受。

在您的sprint计划中，团队是否真的能够实现它，如果是这样的话。如果没有，那么重新思考如何处理这样一个大故事，或者将其分解以提供增值的增量。

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

Answer 3

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

Answer 4

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

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

理想情况下，团队在Backlog Grooming本身期间需要考虑速度 - 这允许Scrum团队从积压中提取他们知道他们将按时完成的故事。 Sprint Planning是生产团队进一步讨论这些整理/大小用户故事的细微差别的地方，以便更好地了解功能需求。