对在sprint期间修改sprint待办事项感到困惑

Question

最近我读了很多关于scrum的文章，我发现在sprint过程中是否可以更改sprint的待办事项，这似乎是相互矛盾的信息。维基百科关于scrum的文章说这是不对的，不同的其他物品也这么说。另外，我的软件开发教授在scrum的概述中也教过同样的东西。

但是，我阅读了来自战壕的Scrum和XP，其中描述了任务板上未计划项目的一节。然后我查找了Scrum指南，它说在sprint过程中“不做任何会影响Sprint目标的更改”，在讨论Sprint目标时，“如果工作结果与开发团队预期的不同，那么他们将与产品负责人合作，在Sprint中协商Sprint的范围”。在讨论Sprint待办事项时，它接着说：

Sprint是一个包含足够详细信息的计划，可以在Daily中了解进展中的变化。开发团队在整个Sprint中修改Sprint，Sprint在Sprint中出现。这种出现是在开发团队通过计划工作并了解更多实现Sprint目标所需的工作时出现的。由于需要新的工作，开发团队将其添加到Sprint待办事项中。随着工作的完成或完成，估计的剩余工作将被更新。当计划中的内容被认为没有必要时，它们就会被删除。只有开发团队可以在Sprint期间更改其Sprint待办事项。Sprint是开发团队计划在Sprint期间完成的工作的高度直观、实时的图片，它完全属于开发团队。

所以在这一点上我完全糊涂了。考虑到这一点，采取第二种方法对我来说更有意义。在我看来，待办事项中的个人特定项并不是最重要的，而是sprint目标，所以不改变sprint目标，而是能够更改待办事项清单是有意义的。例如，如果产品负责人和团队都认为他们对一个故事的看法是一致的，但是随着sprint的进展，他们发现存在一个误解，因此似乎有必要相应地改变构成这个故事的任务。或者，如果有一些故事或任务被遗忘了，但需要达到sprint目标，我认为最好在sprint期间将这个故事或任务添加到积压中。

然而，有很多人似乎非常坚定地认为，对sprint积压的任何更改都是不可以的。我是不是误解了那个位置？难道那些人对sprint待办事项的定义有所不同吗？我对sprint待办事项的理解是，它既包括故事，也包括分解成的任务。

无论如何，我将非常感谢在这个问题上的投入。我试图弄清楚什么是理想的scrum方法在sprint中改变sprint待办事项，以及成功使用scrum进行开发的人是否允许在sprint期间更改sprint待办事项。

Answer 1

首先，我不会对此有严格的规则；scrum的全部目的是让您能够适应这种情况。因此，如果您绝对必要的话，您应该能够在sprint期间修改sprint待办事项(就像您忘记了一些重要的事情一样)。

但是，应该抵制在sprint期间对sprint积压进行这种修改。sprint短的要点是可以将新的工作添加到下一个sprint (在正确排序之后)，而不影响整个项目时间表(多个sprint)。

但是，如果这项工作对于此sprint中的一项任务至关重要，那么您有两个选择。

1. 向sprint.添加新项，但从sprint中删除一个大小相当的项。
2. 删除这个sprint中计划得很糟糕的项目(这样您就可以在下一个sprint中正确地计划它)。
   • 从产品积压的顶部添加一个(适当大小的)替代方案(这应该是您的sprint计划会议的优先顺序)。
   • 或者，当所有sprint项都完成时，可以让dev从产品待办事项中恢复松弛。

因此，我在营地，您可能不应该修改sprint积压。但你必须考虑到情况，可能会有例外的情况。在大多数情况下，我会选择选项2，让开发人员从待办事项中挑选任务。

然后，在下一次计划会议上，将对新任务进行适当的分析，并将其添加到sprint中(视情况而定)。

记住，sprint很短，只是下一个下降的标志，而不是开发周期的结束。产品负责人将不得不非常迫切地想要一个他们不能等待下一次冲刺结束的功能。

Answer 2

这种混淆是由于语言模棱两可。

有两个层次的细节。首先，它是团队承诺交付的项目(用户故事)的列表。第二，这是所有的任务，团队打算做的，以交付每一个故事。

因此，当人们谈论时，他们应该非常清楚自己的意思。当您阅读Scrum指南时，您将看到它声明: Sprint是为Sprint选择的产品待办事项集，再加上交付产品增量和实现Sprint目标的计划。

因此，交付它们的是产品待办事项列表和计划(任务)。

现在，许多团队喜欢在Sprint开始时添加所有建议的任务(计划)，这样他们就可以根据剩下的几个小时来跟踪一个烧毁的图表。其他团队让任务按需要出现。这时添加到“”中是可以的，因为团队必须这样做，以便检查和调整以交付项目和满足Sprint目标。

在某些情况下，一个团队可能比计划提前很多，并且(在消除了所有其他可以提高团队能力的有用任务之后)可能决定与产品负责人一起从Product中选择另一个故事(应该已经有优先级和大小).但是，只有当他们有信心，它将完成在该斯普林特和它符合斯普林特的目标。

所以，我们有了；是的.团队确实会根据需要向Sprint计划添加任务。不，它们通常不会添加到定义Sprint范围的待办事项列表中。

我希望这能澄清情况。

Answer 3

这取决于你的情况。如果在计划过程中遗漏了一些信息，然后您发现需要修改或在一些故事中添加一些要点，那么我认为这很好。但是，是的，如果功能的范围完全改变了，那么这是一个极端的情况，需要进行不同的处理。

但当然，在规划过程中，人们认为每个人都清楚地知道并讨论他们所要做的每一项功能。如果讨论和计划是好的，那么在几乎所有的情况下，你都不需要任何修改。