Scrum-如何将部分完整的用户故事延续到下一个Sprint，而不会导致积压

我们正在使用Scrum，偶尔发现我们无法在计划的sprint中完成用户故事。无论如何，我们都会以真正的Scrum风格交付软件，并考虑在下一个Sprint计划会议期间的下一个Sprint中包括用户故事。鉴于我们要继续执行的用户故事已部分完成，我们如何在下一个Sprint计划会话中对其进行正确估算？我们考虑过：

a）向下调整故事点的数量以仅反映完成用户故事所需的工作。不幸的是，这会使报告产品积压工作变得混乱。

b）关闭部分完成的用户故事，然后提出一个新故事来实施该功能的其余部分，这将减少故事点。这将影响我们回顾性地查看在该冲刺中未完成的工作的能力，这似乎很耗时。

c）不用理会a或b，并在Sprint Planning期间继续猜测，诸如“用户故事可能是X故事点，但我知道它已经完成了95％，所以我确定我们可以适应它”。

在我目前的团队中，我们执行c）。

速度应该说明团队在冲刺中真正完成的事情。没有交付的东西对客户没有任何价值，因此我们不计任何积分，这是全部或全部。

因此，我们将整个未完成的故事转移到下一个冲刺，并将其所有故事点添加到下一个冲刺的速度中。速度会随着时间的推移而逐渐趋于均匀，我们将以前几次冲刺的平均值作为确定未来速度估算的参考。

选项A是通常建议采取的措施。您不会为上一个冲刺的故事完成而分配积分，也不会将故事移回到产品待办事项列表中，从而优先处理该问题。您可以根据已完成的用户案例和增值来计算速度（和其他指标）。当您开始计划下一个冲刺时，您将根据它们的价值来选择优先级最高的故事（如果业务优先级已更改，则可能包含或可能不包含未完成的故事）。当您估计故事时，请包括考虑故事新点数时已经完成的工作。

当然，另一个选择（也是我的喜好）是使用故事点的原始估计数量，这是我过去所做的事情。这假设您的估算是好的且有充分的根据，但是您为冲刺项目付出了太多的努力（例如-故事实际上值3分，但问题在于您在做出选择时就降低了15个故事点）您应该只拉下13）。如果您不确定执行估算的能力，这可能是一个危险的假设，但它可能会根据您的团队和流程而起作用。

但是，您提到这将“弄乱产品待办事项列表的报告”。无论如何，产品待办事项列表都应该是动态的，随着对技术，系统，需求和客户的更多了解，每个故事的订购和估计都将发生变化。通常，从产品待办事项列表中报告的内容是用户故事的数量和故事点的总数。随着优先级的变化，新需求的添加，无效需求的删除以及更多信息的获取，这些变化将有望发生变化。

对此进行过多考虑使它看起来比实际要复杂...实际上很简单：

选项C

不完整的故事可以追溯到产品积压中，而要点不会改变。在计划下一个冲刺以及可以完成的工作时，讨论应包括以下事实：许多工作已经完成。如果团队决定他们可以将其放入冲刺中，那么它将以其原始分数进入。如果没有，它将保留在积压中。做完了 这些点将奖励给完成故事的冲刺。

如果有帮助，您可以针对每个用户故事跟踪一个单独的“剩余工作量”指标，这样，如果在冲刺结束时故事还没有完成，则可以在故事上记录估计的剩余工作量，并考虑何时计划将其包含在后续的sprint中。但是即使如此，也不要改变原始故事的要点价值。

如果您的报表工具无法正确处理选项A，那么除非您不希望使用指标，否则我会选择选项B。

在某些情况下，您可以执行选项B，并且不会通过缩小要关闭的旧任务的范围并仅为剩余的范围创建新任务而使关闭的内容偏斜。这使历史记录在语义上更有意义，并且通常指示您应该考虑进一步分解任务的地方。有时这是不可能或合乎逻辑的，而您只是拥有一项庞大的任务或遇到了此类问题。

编辑： 这是假设的（正如我认为OP所假设的那样），几乎没有完成的工作没有被优先考虑，并且要取得前一次努力的回报，才能使其在列表中保持足够高的水平以继续工作。我知道有些商店不这样做，但是我工作过的大多数地方都认为完成一项接近完成的剩余任务非常有价值，可以简单地继续下去，除非发生了重大变化。更改上下文的代价通常不值得更改顺序。

鉴于我们要继续执行的用户故事已部分完成，我们如何在下一个Sprint计划会话中对其进行正确估算？

我不认为选择A到C都不错，主要是因为什么（我觉得）应该是关于球队的速度最重要的是它的平均的速度，而不是任何给定的冲刺速度是否涨跌互现。

定义用户故事后，应具有接受条件。如果验收标准中的任何内容未完成，则团队根本不会获得任何积分。如果故事是完成的（即由PO编码，测试并接受），则团队将获得所有分数。

这种运作良好，当团队正专注于它的平均的速度，而不是在一个给定的冲刺的速度。

像科恩（M. Cohn）的书一样，我倾向于偏偏全有或全无的情况。毕竟，尝试估计您是否已经从8分故事中获得了5分，或者仅仅是6或7，最终将成为另一种猜谜游戏...并且不要忘记您已经获得了最初的估计出路。最好只使用最简单的方法，然后在真正完成之后获得所有要点。

引用科恩先生的书¹（我的重点）：

我通常赞成采用全有或全无的态度来计算速度：如果完成了一个故事（编码，测试并被产品所有者接受），那么团队将获得所有积分，但是如果故事中没有任何内容没做，他们什么也没赚。在迭代结束时，这是最容易评估的情况：如果一切完成，他们将获得所有分数；如果缺少任何东西，他们将得不到任何分数。如果团队可能在下一次迭代中承担故事的其余部分，则效果很好。他们在第一次迭代中的速度比预期的要低一些，因为他们没有完全相信故事的完成。但是，在第二次迭代中，它们的速度将比预期的要高，因为即使在迭代开始之前已经完成了一些工作，它们也会得到所有要点。只要每个人都记得我们对团队随时间推移的平均速度最感兴趣，而不是对给定迭代中速度是跳跃还是跳跃，这个方法就可以奏效。

¹ 敏捷估计和规划，重新估计部分完成的故事，第66页

尽管有一些反对意见，我的团队以前还是尝试分配部分分数，我认为这一点都不奏效。（我们不这样做了...去图）这是因为故事都应该得到特别是估计的情况下作为一个团队，但如果只有一个人工作就可以了，它会在更困难的小组，以知道一个人实际完成了多少。敏捷对团队的平均速度更感兴趣，而不是对特定冲刺的“好”外观感兴趣。

话虽如此，但作者确实提到，如果团队不太可能在下一次迭代中解决剩余的工作，则可以考虑分配部分积分。在这种情况下，团队将估算剩余的工作并将其分解为新的用户故事，以他们认为应该拥有的大小为限。正如作者所提到的²：

合并的估算值不必等于原始估算值。

²同上，第66页

对于团队来说，更好的建议是将故事分解成足够小的规模，以避免出现此类问题³：

但是，为不完整的故事分配点的两个最佳解决方案是不包含任何不完整的故事，并使用足够小的故事以使部分信誉不成问题。

³同上，第67页

希望这可以帮助。

我很惊讶似乎没有一个直接的答案。我期待着“选项D，虚拟”的合唱！

由于我们似乎并没有遗漏任何明显的东西，因此我们认为这是每个团队需要根据自己的工作方式和最重要的指标自己做出的决定之一。

我们认为，准确记录已实施的用户故事至关重要，因为它们构成了我们测试，支持文档和发行说明的基础-排除了选项B。

接下来，我们认为能够准确执行冲刺计划是必不可少的-排除了选项C。

因此，我们得出结论，备选案文A对我们来说是正确的。我们将重新估计在冲刺中部分完成的所有故事的故事点，以便我们可以在后续冲刺中为它们进行适当的计划。随着时间的推移，积压的产品将略微不足以报告我们已实现的故事点的数量，但这将比其他任何选项都没有问题，可以通过更改记录和报告来解决。

我们会跟踪为达到大写目的而在sprint迭代中花费的时间（花费在与用户故事相关的任务上的时间），如果PO的目标是在下一个sprint中继续进行卡车运输，则将针对性的用户故事移动到一起，点相同。

如果PO的目标是将其他事情移到原处，那么我们只需将未完成的故事放入待办事项中，然后做他们想做的任何事情。我的建议是保留分数的原始估计值，因为如果您习惯于忍耐不止嚼，每次冲刺都会“完成”故事冲刺中的故事点，而这些冲刺并没有完全完成和清理，测试项目。

如果您确实想在冲刺中留下某些东西，或者指出要发送的东西，或者我认为您必须发货，那么我认为您应该在原始故事中确定一个切入点，并在此切入点到达完成点，并提交较小的部分为您的迭代。然后可以将其余部分重新指向，并放入积压中。这将是一个重新评估的机会，因为您同意您的团队将故事分解为几部分。

要问的第一个问题是“故事点”是什么意思？如果您将故事点定义为“完成多少工作”，那么任何答案都可以。但是，如果将故事点定义为“为企业带来了多少价值”，那么在故事完成100％，接受并交付100％之前，不要给与信用就很重要。在冲刺之后根据完成的内容修改故事点只会隐藏真正的问题：a）对故事没有清晰的了解，b）故事定义太粗糙，c）故事缺乏可衡量的接受标准，d ）对完成故事的任务或依赖项没有足够的了解，e）低估了测试故事的努力，f）提取了太多的故事要点，或g）...在这里插入您的理由...

敏捷的目标是在可预测的同时保持灵活性。我认为，保持一致的最佳方法是在不修改原始故事估算的情况下找出问题所在。