您认为可以对用户故事进行哪些类型的更改/添加/进一步说明？
您认为用户故事发生哪些更改/添加/进一步说明是不合适的？
【问题讨论】：
标签： scrum
什么类型的变化/添加/进一步 你认为可以澄清吗 制作用户故事（在 sprint 开始后）？
产品负责人要求和让 Scrum 团队仍然舒适保持他们对完成所有用户故事的承诺在冲刺中。
什么变化/添加/进一步 你认为不妥当的澄清 是否发生在用户故事中（在 sprint 开始之后）？
产品负责人要求并使 Scrum 团队不舒服维持他们对完成所有用户故事的承诺冲刺。
【讨论】：
我认为这一切都取决于团队与产品负责人的谈判。在某种程度上，对用户故事进行任何影响故事实施的更改都是不妥的。
团队承诺的是在 sprint 计划期间指定的用户故事。稍后引入的任何更改都不属于承诺的一部分，因此产品负责人（假设这是更改的来源）应该知道任何需求更改都需要由团队签署。
再一次，这是一种非常严格的处理方式。
对于更真实的答案，我想说对用户故事的任何更改都需要提交给团队并进行协商。团队应该能够估计实施更改所需的额外时间，并基于此提交更改的用户故事与否。如果这些变化很小，那么您很可能只需将工作负载添加到正在运行的 sprint 中，而不会产生任何风险。如果需要更多努力，请提出一个不会使 sprint 面临风险并得到团队和产品负责人同意的解决方案。这些可能是：
即使由于原始需求在某些方面被证明是“错误的”而弹出更改的需求，我仍然认为团队所承诺的才是最重要的。因此，如果产品负责人认为用户故事没有价值并且需要更改，这不是将所有更改的需求带入 sprint 的正当理由。如果应用更改的努力会使 sprint 的其余部分面临失败的风险，那么更好的选择是放弃此 sprint 的更改故事，并在下一个 sprint 计划期间再次提出更改。
【讨论】：
用户故事的重点是定义对客户有价值的功能。如果该定义的任何方面发生变化，你最好改变故事。
另一方面，您的故事点估算是基于旧故事和旧的接受标准 - 如果对用户故事的更改显着增加了完成它所需的时间，您将不得不拆分故事并移动部分将它（或另一个较低优先级的故事）放到另一个 sprint 中。
这还取决于您距离 sprint 结束有多近 - 如果明天是 sprint 的最后一天，只需制作一个新故事来表达更改并将新故事添加到下一次迭代（或之后的迭代） ，取决于其紧迫性）。
【讨论】：
正如我最近在回答另一个堆栈溢出问题时提到的，我认为 Martin Fowler 在Conversational Stories 上的博客文章非常适合回答有关用户故事的问题。
应始终欢迎在对话中进行澄清。如果团队认为有时间在当前 sprint 中完成请求的更改，则应该允许不改变整体故事的更改。并且添加的内容通常应该是新故事，除非团队认为他们有时间并且在当前的 sprint 中更容易完成。
所以总体答案是“视情况而定”，但我认为使用上述指南将帮助每个人为团队做出最佳决定。
【讨论】：
您可以取消冲刺。或者可能将麻烦的项目转移到新的冲刺？从而减少当前sprint的长度。但本质上我说，任何会严重影响 sprint 的长度或输出的东西都是我们的决策点。只有你才能真正评估我想说的。
【讨论】：