在Scrum中，一个Sprint期间更改验收标准是否可行？

Question

我的机构目前正在实施Scrum。在处理一个产品待办事项以改变某些业务逻辑的方式时，我们发现部分业务逻辑是有缺陷的。目前该PBI及其验收标准是针对修改现有业务逻辑的实现方案。PO认为这种对业务逻辑本身的更改很重要，应该以某种方式纳入Sprint中，而开发团队也同意，特别是从开发角度来看，同时进行两件事情会更有意义。

然而，我们不确定是修改验收标准还是创建一个新的PBI并立即将其拉入Sprint更合理。我个人倾向于创建一个新的PBI，因为我认为这是一个与原来PBI不同的故事和一组验收标准，并且我对在Sprint期间更改验收标准持怀疑态度。PO指出，这个新的需求和原始的PBI将同时实施，如果不能解决新需求，原始的PBI就没有意义了。因此，PO认为调整原始PBI的验收标准而不是创建反映最终相同实现的两个单独的PBI更合适。

哪种方法更符合Scrum？

- scott degen

---

这个问题不在本站的范围之内，因此属于不适当的话题。请参阅我可以在这里问什么样的问题？和哪些类型的问题应该避免提问？。你可以尝试在其他 Stack Exchange 网站上提问，例如[pm.se]或[softwareengineering.se]。请务必阅读帮助中心的相关页面，了解您打算发布问题的任何网站的主题内容。 - Makyen

Answer 1

你应该只在团队达成共识的情况下修改故事，因为他们已经致力于交付一个确定的标准。如果你未经团队全面同意更改标准，那么一开始为什么要得到它呢？

更改Sprint Backlog是一件大事，因为这样会贬低团队在Sprint期间交付特定故事的承诺。

如果团队不愿接受更改，则PO可以撤回原始故事并将新故事置于待办事项列表的顶部。它可能被包含在当前Sprint中，也可能不会。

强烈抵制PO在Sprint期间干预Sprint Backlog的想法。我的PO试图在最近一个Sprint结束时插入一个非常小的故事（基于某些非常错误的理由）。

来自http://www.scrum.org/scrum-guides/：

只有开发团队可以在Sprint期间更改其Sprint Backlog。

我认为这是个好建议，你应该非常谨慎地忽视它。

- David M

Answer 2

在Scrum中，有一些微妙的差别需要理解。在Sprint Planning中，产品负责人根据团队的速度，向团队提供下一个最有价值的需求，并说明要求，团队对细节进行提问。请注意：这不应该是团队第一次看到需求，因为他们应该在预备会议上看过它。团队讨论他们的方法，做出设计并创建大量任务，并同意预测。团队生成Sprint backlog、Sprint目标并开始工作。没有人可以更改团队正在处理的核心需求，甚至团队也不能。只有当PO认为没有继续下去的价值时，才有权终止工作。这里有一个微妙的界限，区分PO方面的不良计划和需求澄清。需求不是合同，团队应该只关注必须完成的核心内容。细节应该被收集，并略微改变以完成需求。团队完全可以更改他们正在处理的任务，添加更多任务或删除任务来帮助沟通和协作，只要这样做是为了交付所请求的需求。详细说明是完全可以接受的。大多数团队面临的挑战是，澄清会改变需求的含义。当发生这种情况时，您应该在回顾中迅速解决问题，并适应书写需求的方式，从而消除歧义。这意味着您需要花更多时间进行预备会议。回答您的问题，请如果PO和团队认为有必要修改某些内容...请修改。然而，这应该是例外而不是规则。如果经常发生这种情况，则说明您的预备会议不好。澄清验收标准并提高Sprint质量是没有问题的。

- Brett Maytom PST

Answer 3

在这种情况下，我们通常让产品负责人从Sprint中删除原始用户故事，以便为Sprint腾出时间。利用这段空闲时间，PO可以要求将新的用户故事（带有更新的验收标准）包含在Sprint中。当然，前提是新的用户故事能够在Sprint剩余的时间内完成。

通过将过程分成两个独立的步骤，确保PO了解必须在添加更多内容之前从Sprint中移除一些工作，使该过程抵制未来的范围蔓延。

- NickGPS

Answer 4

一般来说，一旦估算了票（PBI），尤其是在冲刺期间，更改AC是绝对不可以的。但是，你必须问一下这样做会引起什么问题。换言之，更改AC可能会导致估算不准确，也就是太低了。那又怎样？嗯，这可能会导致团队无法完成冲刺中承诺的任务。这很糟糕。

在这种情况下，新的票据可能不是一个好主意，因为它听起来不符合INVEST故事的“独立”标准。

修改当前的票据可能会在尝试跟踪冲刺中添加的故事/点数时引起一些会计问题，但除此之外，我没有看到任何问题。关键在于重新估算，以便每个人都明白这是更多的工作。

尽量不要陷入“Scrum适当”的困境。考虑一下什么有效，不同的事物会引起什么问题，并根据这些做出决定。

最后，确保在回顾会议中讨论这个问题，以便讨论为什么在这种情况下AC不正确或不完整，并查看团队是否可以采取可行的步骤来防止未来发生类似情况。

附注：您可能会在pm.stackexchange.com上找到更多关于这类问题的帮助。

- Jody

Answer 5

我很快地浏览了一下你的问题。这是解决方法。我们曾经遇到过类似的情况。我们创建了一个增量故事，从当前迭代中取出一些内容，并将其移动到另一个迭代中。只需称之为DELTA US并给出版本1.1。

有帮助吗？

谢谢， Kris。

- Kris