在scrum中，在sprint期间更改验收标准可以吗？

Question

我的组织目前正在实现Scrum。在处理产品待办事项以更改处理某些业务逻辑的方式时，我们意识到一些业务逻辑是有缺陷的。PBI及其验收标准目前面向修改现有业务逻辑的实现。PO认为业务逻辑本身的这种变化是高优先级的，应该以某种方式工作到冲刺中，开发团队也同意这一点，特别是从开发的角度来看，同时做这两件事很有意义。

然而，我们不确定修改验收标准或创建新的PBI并立即将其拉入sprint是否更有意义。我个人倾向于新的PBI，因为我觉得这是一个独立的故事和一组与原始PBI不同的验收标准，而且我对在冲刺中期改变验收标准持怀疑态度。采购主任指出，这一新要求将与原来的PBI同时实施，如果没有新的要求需要解决，原来的PBI是没有意义的。因此，PO认为调整原始PBI的验收标准会更合适，而不是创建两个单独的标准来最终反映相同的实现。

其中一种方法比另一种更适合scrum吗？

Answer 1

您应该只在团队同意的情况下修改故事，因为他们承诺交付一组标准。如果你在没有得到团队的一致同意的情况下更改了标准，那么你为什么要在一开始就麻烦地得到它呢？

摆弄sprint的积压工作是一件很大的事情，因为这样做会贬低团队在sprint期间交付特定故事集的承诺。

如果团队不愿意接受更改，PO可以撤回原始故事，并将新故事放在积压的顶部。它可能包含在当前的sprint中，也可能不包含。

抵制你的每一根纤维，即PO可以在sprint期间摆弄sprint backlog。我的PO试图在最近的一次冲刺接近尾声时丢弃一个非常小的故事(基于一些非常虚假的推理)。

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

只有开发团队可以在冲刺期间更改其冲刺积压。

我认为这是一个很好的建议，你应该带着极大的恐惧忽略它。

Answer 2

对于Scrum，有一些细微的区别需要理解。

在Sprint Planning中，产品负责人根据团队的速度向他/她想要交付的团队提供下一个最高价值的需求。采购订单解释需求，团队对采购订单的细节提出质疑。

注意:这不应该是团队第一次看到需求，因为他们之前在美容会议中就应该看到了。

团队讨论他们的方法，做他们的设计，并创建一堆要做的任务，并同意预测。团队产生一个冲刺积压，冲刺目标，并开始工作。

没有人可以改变团队正在处理的核心需求；即使是团队也不能。只有PO有权终止工作，如果他/她认为继续工作没有价值。在PO方面的糟糕计划和对需求的澄清之间只有一条细微的界限。

需求不是合同，团队应该有核心来做必须做的事情。应该收集细节，并稍微修改工作，以完成要求。团队可以完全更改他们正在处理的任务，添加更多任务或删除任务，以帮助沟通和协作；但前提是交付所请求的需求。澄清细节是完全可以接受的。

大多数团队面临的挑战是在哪里澄清，改变需求的含义。当这种情况发生时，您应该在回顾中将问题扼杀在萌芽状态，并适应您编写需求的方式；从而消除歧义。这只是意味着你需要花更多的时间来修饰。

来回答你的问题。如果PO和团队觉得改变一些东西是有意义的……去做吧。然而，这应该更多的是例外而不是规则。如果它一直都在发生，那就是你的仪容不好。在Sprint中澄清验收标准和提高质量没有错。

Answer 3

在这种情况下，我们通常让产品负责人从冲刺中删除原始的用户故事，这在冲刺中腾出了时间。有了这段空闲时间，PO可以请求将新的用户故事(具有更新的验收标准)包括在sprint中。当然，有一个假设是，新的用户故事可以在sprint的剩余时间内完成。

通过将流程分成两个独立的步骤，它确保PO理解一些工作必须来自冲刺，然后才能有更多的工作进入，从而使流程能够抵抗未来的范围蔓延。