是对用户故事的新更改请求，是不同的用户故事。

Question

我们已经完成了一个短跑的用户故事。在sprint的末尾，为同一个用户故事请求了一个新的功能添加。

在这里，用户故事将保持不变。作为一个<user>，我想要<>，这样<>就会保持不变。唯一的区别是，有一个新的价值增值是要做的。

因此，这是作为下一次冲刺的新用户故事还是应该被看作是一个待办事项？

我们已经满足了我们对用户故事的定义，这个新特性是一个新的要求，在用户故事定义中不会有任何变化。

我正在增加一个例子，以使它更加清楚。

采用一个功能，如创建配置文件，在该用户可以更新他的名字，地址，电话号码，照片等，并完成。现在，如果客户想要拥有facebook链接或将国家代码添加到电话号码中，那么这是一个新的用户故事吗？

Answer 1

为你的新需求做一个新的故事。

标题中的问题可能没有一般性的答案，但让我们考虑一下您的例子：

As a user I want to maintain a user profile

假设您已经完成了这个故事的定义，包括编辑和保存家庭地址、电话号码和其他一些东西的能力。产品负责人同意了，这个故事被估计了，并被拉进了sprint。后来，它被标记为已完成，并赢得了故事的积分。

如果你改变这个故事，这将导致原故事的范围改变。它也显示了你的工作倦怠下降，即使你交付了高质量的工作之前，它是商定的。见这个相关的问题。创造一个新的故事，接受它是微小的，当你需要用一些小的东西来填充你的冲刺时，把它拉进来。

学习这一点，并使调整每次迭代完成的定义在结束前包含一次重覆，以防止在为时已晚之前添加一些琐碎的内容。

Answer 2

一旦一个故事在冲刺中被承诺，这个故事就不应该再被允许改变了。

现在，如果用户在sprint过程中提出了一个新的想法，它会影响到那个sprint中的一个故事，那么有几种方法可以处理这个问题：

• 中止sprint并开始计划一个新的sprint。这将产生巨大的影响，通常是最后的选择。如果客户端的新想法完全使当前正在进行的工作无效，则主要是有用的。
• 从sprint中移除受影响的故事。如果有几个故事被这些新想法所失效，并且被认为是零(甚至是负的)值，那么您可以与客户机协作，决定从当前的sprint中删除这些故事。由此产生的工作空白可以由产品积压的工作来填补。
• 以故事的形式加入新的想法。这应该是最常见的选择。如果原始故事仍然有价值，按计划完成它们，并将新的想法作为附加的故事添加到产品待办事项中。
• 如果更改非常小(会导致一个<1个故事点的故事)，并且故事还没有完成，那么您可以决定将这些更改与原始的故事实现一起进行。这种选择应该是罕见的。

在您的“创建配置文件”故事的例子中，附加的故事可能是用户希望存储一个Facebook链接以及配置文件中的其他信息。

更改是变更请求(通常是单独计费的)还是属于正常工作范围的问题取决于您与客户的合同，并由帐户经理处理。

Answer 3

就文档和在严格的Scrum框架中处理更改而言，它应该作为一个新的用户故事来处理，并且不允许进入现有的迭代，但是.

让我们讲求实际，不要造成不必要的开销.这不是敏捷。如果编码/测试的复杂性/工作量如此之小，以至于创建、排序和管理新故事所需的时间较长，而不是在现有故事下修改和完成，那么就走更精简的路线，只需更新现有的故事即可。

请记住，一旦您进行了增强，您的开发人员可能需要在进行更改之前再次对代码进行热身。有时，它更有效，仅仅是做修改，并跟踪变化与现有的故事。