优先权的变化
我知道这种类型的问题已经被问过很多次了，而且添加新的故事应该在待办事项列表中，除非它使当前的sprint成为泡影。
但下面哪些答案是正确的？
非常感谢。
客户机在特定功能的优先级上有一个重要的变化，并且希望在sprint中期添加一个新的用户故事。产品经理可以通过哪些方式处理这种情况？
- 告诉客户，在sprint中期，由于任何原因都不能添加故事
- 与团队一起确定可以从sprint中提取哪些内容，以便在sprint中添加此功能
- 与客户讨论交换输入/输出用户故事的影响
- 让客户知道，该功能没有他认为的那么重要，还有其他优先级可以提供更多价值
- 停止sprint工作，用客户机的新需求重新规划sprint的其余部分
3是我从Scrum的角度看到的唯一有意义的答案，但实际上它们都表明了一些不是Scrum实践的东西。
伊恩暗示的问题是“什么是冲刺目标”？
如果故事有助于实现sprint目标，并且可以在不危及sprint目标的情况下引入或替换现有故事，那么就没有真正的问题，但这是由团队来决定的，而不是PO（或者当然是不存在的PM角色）
但在现实中，他们可能在谈论与sprint目标无关的事情，因此应该进入产品待办事项列表，由PO确定优先级，并有可能为下一个sprint做好准备。
支撑这一切的是让我最不安的部分，那就是“客户”这个词。
Scrum团队本质上是一个产品团队。他们应该关心顾客。客户开始觉得他们是某种瀑布式交付团队，为某个利益相关者交付规范。“客户”的需求仅与关键利益相关者相关。
在采购订单的指导下，应指导团队为客户交付产品目标。
这个问题是从哪里来的？对于像“产品经理”和“用户故事”这样的术语，我想问作者是否理解Scrum框架。
看看答案，没有一个真的那么好。
告诉客户，在sprint中期，由于任何原因都不能添加故事
这不是真的。开发人员管理Sprint积压工作，因此需要由开发人员来决定是否可以更改Sprint积压中的工作。这个决定应该根据实现冲刺目标的能力做出。也许它是由产品负责人传达给利益相关者的，但这通常不是产品负责人的决定。
一种可能由产品负责人决定的情况是，新产品积压项所代表的工作是否比团队为Sprint选择的任何工作都不重要。即使特定的利益相关者可能认为它应该更重要或具有更高的优先级，产品负责人也有责任做出有关订购产品积压的决策。产品负责人可以决定不将新工作带到团队中，因为他们觉得它不如当前正在完成的工作重要。
与团队一起确定可以从sprint中提取哪些内容，以便在sprint中添加此功能
这是一个可行的选择，但并非总是如此。缺少两个关键因素。
首先，没有提到冲刺目标。Sprint的目的不是交付所有选定的产品待办事项，而是实现Sprint目标。团队应首先确定这项新工作对实现Sprint目标能力的影响。只要Sprint目标没有过时，那么团队就应该继续致力于此。
其次，这并不能说明团队有良好的能力规划。定期接收临时请求的团队应在其能力范围内为这些高优先级临时或计划外请求留出缓冲区，以便他们能够处理这些请求。制定冲刺目标时应牢记这一点。一个满负荷的团队也不会为任何意外事件留下任何空间。也许这不是计划外的工作，而是计划外的容量减少。
与客户讨论交换输入/输出用户故事的影响
这也是一种可能性。然而，它没有提到Sprint目标。也许这是暗示，但我不确定这是否是问题和答案的其他问题。任何关于影响的讨论都应该考虑诸如冲刺目标、团队能力以及保持可持续速度的能力。
让客户知道，该功能没有他认为的那么重要，还有其他优先级可以提供更多价值
这也是一种选择。然而，没有足够的上下文来确定这项工作是否不那么重要。产品负责人无疑是负责就订购工作和实现价值最大化做出决策的人。特别是在存在多个利益相关者的情况下，产品所有者需要平衡所有利益相关者之间的需求。
停止sprint工作，用客户机的新需求重新规划sprint的其余部分
这是Scrum中的一个选项-产品负责人可以取消Sprint。然而，它并不常用，是一个非常极端的选择。它只应在Sprint目标过时的情况下使用。由于问题或答案中没有提到Sprint目标，我不确定情况是否如此。
从产品负责人的角度来看，3和4是产品负责人可以自己做的事情。2也是一个可行的选择，但经常处于2发生的位置通常表示存在其他问题。5也是一种可能性，但不是我推荐的。不清楚正确的答案是什么。我认为没有足够的信息来支持4，所以我可能倾向于3，这是一件总体上很好的事情。如果这种情况经常发生，解决根本原因将是一个更好的选择。
