我的组织目前正在实施Scrum。在处理产品积压项目以改变处理某些业务逻辑的方式时，我们意识到某些业务逻辑存在缺陷。 PBI及其接受标准目前面向修改现有业务逻辑的实现。 PO认为对业务逻辑本身的这种改变是一个高优先级，并且应该以某种方式进入sprint，并且开发团队也同意，特别是因为从开发的角度来看将两者结合在一起会很有意义。
但是，我们不确定是否更有意义修改验收标准或创建新的PBI并立即将其拉入sprint。我个人倾向于使用新的PBI，因为我觉得这是一个单独的故事和原始PBI的验收标准，我对改变一般冲刺中的接受标准持怀疑态度。 PO指出，这一新要求和原始PBI将同时实施，原始PBI毫无意义，无需解决新要求。所以PO认为调整原始PBI的验收标准更合适，而不是创建两个最终反映相同实施的独立标准。
这些方法中的一种是否比其他方法更适合？
答案 0 :(得分：4)
您应该仅在团队同意的情况下修改故事，因为他们承诺提供一组标准。如果您在没有团队的一致同意的情况下更改标准，那么为什么还要在第一时间获得它呢？
摆弄冲刺积压是一件大事，因为那时你贬低了团队在冲刺期间提供特定故事的承诺。
如果团队不愿意接受这些更改，那么PO可以撤回原始故事，并将新故事放在积压的顶部。它可能包含在当前的sprint中，也可能不包括在内。
在冲刺期间，PO可以摆弄冲刺积压的概念，抵抗你的每一根纤维。我的PO试图在最近冲刺结束时放弃一个非常小的故事（基于一些非常虚假的推理）。
来自http://www.scrum.org/scrum-guides/：
只有开发团队可以在a期间更改其Sprint Backlog 冲刺。
我认为这是一个很好的建议，你应该非常惶恐地忽视它。
答案 1 :(得分：4)
Scrum有一些微妙的差异。
在Sprint Planning中，产品所有者根据团队速度向团队提供他/她想要交付的下一个最高价值的要求。 PO解释了要求，团队向PO询问具体细节。
注意：这不应该是团队第一次看到要求，因为他们应该在修饰会议之前看到它。
团队讨论他们的方法，进行设计并创建一系列任务并同意预测。该团队制作冲刺积压，冲刺目标并开始工作。
没有人可以改变团队正在进行的核心要求;甚至不是团队。如果他/她认为没有继续使用它的价值，那么只有PO才有权终止工作。在PO方面的糟糕计划与要求的澄清之间存在一条细线。
要求不是合同，团队应该拥有必须完成的核心。应收集细节并稍作改动以完成要求。团队可以完全更改他们正在处理的任务，添加更多任务或删除任务以帮助沟通和协作;只要提供所要求的要求。澄清细节是完全可以接受的。
大多数团队面临的挑战是澄清，改变要求的含义。当这种情况发生时，你应该在回顾中将问题扼杀在萌芽状态，并适应你写作要求的方式;从而消除歧义。它只是意味着你需要花更多的时间进行梳理。
回答你的问题。如果采购订单和团队认为改变某些事情是有道理的，那就去做吧。但是，这应该是比规则更多的例外。如果它一直在发生;你的修饰很糟糕。在Sprint中澄清验收标准和提高质量没有任何问题。
答案 2 :(得分：2)
在这种情况下，我们通常会让产品负责人从sprint中删除原始用户故事，从而在sprint中释放时间。利用该空闲时间，PO可以请求将新用户故事（具有更新的接受标准）包括在sprint中。当然，假设新用户故事可以在sprint的剩余时间内完成。
通过将流程分为两个单独的步骤，它可以确保PO了解某些工作必须在冲刺之前完成，然后才能进入，从而使流程能够抵御未来的范围蔓延。
答案 3 :(得分：1)
通常，一旦估算了票证，特别是在冲刺中，更改票证（PBI）的AC是一个很大的不可能。话虽如此，你必须问它可能导致什么问题。
即更改AC可能导致估计不正确 - 即太低。所以呢？那么，这可能会导致团队无法完成sprint的承诺门票。那很糟。
在这种情况下，新票可能是一个坏主意，因为它听起来不符合INVEST故事的“独立”标准。
在尝试跟踪sprint的已添加故事/点时，修改当前故障单可能会导致一些会计问题，但除此之外我没有看到任何问题。这里的关键是重新估计所以每个人都明白这是更多的工作。
尽量不要陷入“适合Scrum”的行列。想想什么有效，不同的事情会给你带来什么问题，并根据这些做出决定。
最后，请确保在回顾展中出现此问题，以便您可以在此案例中讨论AC不正确或不完整的原因，并了解该团队是否可以采取可采取措施以防止将来发生这种情况。
PS你可以在pm.stackexchange.com找到更多关于此类问题的帮助
答案 4 :(得分：0)
我很快就解决了你的问题。这就是事情。我们有类似的情况。我们创建了一个三角洲故事，并将当前冲刺中的东西拉出来并将其移至另一个冲刺阶段。只需将其命名为DELTA US并提供1.1版本。
有帮助吗？
谢谢， 克里斯。