对在冲刺期间修改冲刺积压感到困惑

最近，我已经阅读了很多有关Scrum的文章，并且发现在冲刺期间更改冲刺积压是否可行，这在我看来似乎是相互矛盾的信息。在对Scrum的维基百科的文章说，这是不正常，以及各种其他文章说的这一点。我的软件开发教授也在scrum概述中讲了同样的事情。

但是，我从Trenches中阅读了Scrum和XP，并介绍了任务板上计划外项目的一部分。因此，我查阅了《Scrum指南》，它说在sprint期间“未进行会影响Sprint目标的任何更改”，并且在讨论Sprint目标时“如果工作结果与开发团队的预期不同，然后他们与产品负责人合作，在Sprint中协商Sprint Backlog的范围。” 在Sprint待办事项的讨论中，它继续说：

Sprint Backlog是一项计划，其细节足够详细，可以在Daily Scrum中了解进度的变化。开发团队会在整个Sprint中修改Sprint Backlog，并且在Sprint期间会出现Sprint Backlog。在开发团队仔细研究计划并了解有关实现Sprint目标所需工作的更多信息时，就会出现这种情况。

由于需要进行新工作，因此开发团队将其添加到Sprint Backlog中。随着工作的完成或完成，估计的剩余工作将更新。当计划中的要素被视为不必要时，将其删除。只有开发团队可以在Sprint期间更改其Sprint Backlog。Sprint待办事项列表是开发团队计划在Sprint期间完成的工作的高度可见的实时图片，它完全属于开发团队。

因此，在这一点上我完全感到困惑。考虑一下，采用第二种方法对我来说更有意义。在我看来，待办事项中的各个特定项目不是最重要的，而是冲刺目标，因此，不更改冲刺目标，但能够更改待办事项很有意义。例如，如果产品负责人和团队都认为他们在同一个故事页面上，但是随着sprint的进行他们发现存在误解，则似乎有必要相应地更改构成该故事的任务。或者，如果有一些故事或任务被遗忘了，但是达到冲刺目标是必需的，我认为最好在冲刺期间将故事或任务添加到待办事项中。

但是，很多人似乎非常坚决认为对sprint待办事项的任何更改都不可行。我是否会以某种方式误解该职位？那些人对冲刺积压的定义是否有所不同？我对sprint待办事项的理解是，它既包括故事，也包括被分解成的任务。

无论如何，我将非常感谢您对此问题的投入。我试图找出理想的Scrum方法在冲刺期间更改sprint积压是什么，以及成功使用scrum进行开发的人是否允许在冲刺期间更改sprint积压。

首先，我对此没有硬性规定。Scrum的全部目的是让您适应情况。因此，如果绝对必要，您应该能够在sprint期间修改sprint积压（例如，您忘记了一些关键的内容）。

但是，应该拒绝在冲刺期间对冲刺积压的这种修改。sprint的简短之处在于，可以将新工作添加到下一个sprint（在正确确定优先级之后），而又不影响整个项目时间线（多个sprint）。

但是，如果这项工作对于此Sprint中的一项任务至关重要，则有两种选择。

1. 将新项目添加到sprint。
   但是从sprint中删除一个大小相等的项目。
2. 从该Sprint中删除原本计划不好的项目（以便您可以在下一个Sprint中适当地计划它）。
   • 从产品待办事项列表的顶部添加一个替代项（大小合适）（应按冲刺计划会议的优先顺序）。
   • 或者，当所有sprint项目完成时，允许开发人员从产品积压的订单中获利。

因此，我在营地中可能不应该修改sprint积压。但是您必须考虑到可能存在特殊情况的情况。在大多数情况下，我会选择选项2，让开发人员通过积压的任务来解决问题。

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

请记住，冲刺很短，只是下一滴的标记，而不是开发周期的结束。产品负责人必须非常迫切地希望不能等待下一个Sprint结束的功能。

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

Sprint Backlog有两个详细级别。首先，它是团队已承诺交付的项目（用户案例）的列表。其次，团队打算完成所有任务以传达每个故事。

因此，当人们谈论Sprint待办事项列表时，他们应该真正清楚其含义。阅读《 Scrum指南》时，您会看到以下内容：Sprint待办事项列表是为Sprint选择的产品待办事项项目集，以及交付产品增量和实现Sprint目标的计划。

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

现在，许多团队喜欢在Sprint的开头添加所有建议的任务（计划），以便他们可以根据剩余的工作时间来跟踪燃尽图。其他团队让任务按需出现。这是可以添加到“ Sprint待办事项列表”的时候了，因为团队必须这样做以便检查和调整以交付项目并达到Sprint目标。

在某些情况下，团队可能比计划提前了（并且消除了所有其他可以改善团队能力的有用任务），可以决定与产品负责人一起从中选择另一个故事（应该已经确定了优先级和大小）。产品待办事项列表...，但前提是他们有信心在该Sprint中完成该任务并与Sprint目标保持一致。

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

我希望这可以澄清情况。

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

但是，当然，在规划过程中，假定每个人都清楚地知道并讨论了他们将要使用的每个功能。如果讨论和计划很好，那么在几乎所有情况下，您实际上都不需要任何修改。

我同意答案，我要指出的是，如果这个故事已经开始发展，那么直到完成后它才能停止。

尽早挖掘脚跟。那些要求改变的人将不得不学习艰难的方法，否则，如果人们学会了无论如何都能做自己喜欢做的​​事情，那么最终您将计划变得毫无价值。

引用质量来自焦点，错误来自于丢掉思路。引用上下文切换的成本。跟踪债务以及管理写作，讨论和播放故事以处理半成品的成本很高。只是不要从这条路开始。

想法：给管理层3个转换信贷，让每个季度都花一个折衷方案。