如何重新评估未完成的工作

当团队没有在当前Sprint里完成所有的工作，我们该怎么办？

我们也许听到过如下的建议：

• 拆分用户故事，以便我们能获得已经完成的工作的积分

• 这个用户故事已经完成90%了，我们移到下个Sprint并将13点改为1点

• 这几个用户故事我们没有完成，直接带到下个Sprint

• 这个用户故事我们评估的太少，应该增加到13点

• 开发已经完成了，我们可以关掉这个用户故事，然后创建一个测试的故事

在正常情况下，评估原本就是很困难的。然后考虑当团队的评估"错误"该怎么办时，这将会使团队的工作变得更加困难、混乱。

团队对于未完成的工作，到底应该怎么办？

1. 从来不重新评估未完成工作项

团队不需要重新评估未完成的工作，因为这不符合"完成" (DoD)的定义。未完成的工作项需要返回到产品待办列表（Backlog）里，团队应该在下一个迭代（Sprint）里重新审视和检查它们。

DoD是非常有力量的工具，就像二进制只是一系列1和0一样，完成的定义只有两种状态，"完成"和"未完成" 。在Sprint结束时，团队查看每个产品工作项，并询问这是否符合"完成" 的定义？如果答案是肯定的，则转到Sprint评审。如果答案是否定的，那么它将返回到产品待办列表 。

2. 始终关注价值交付

如果"未完成"（包含"部分完成"）的工作对于用户不可用，那么它就没有产生任何价值。团队需要将"未完成工作"返回到产品待办列表，并且把"未完成工作"当作没有做任何工作。团队应该像处理产品待办列表的其它工作一样对待该“未完成工作”。

为什么不需要重新评估未完成工作项

1. 团队完成的工作必须对用户可用

根据Scrum指南 – "每个 Sprint的工作增量必须是可用的，这样才能确保团队在持续地给用户交付价值。"

不能为了获得部分功劳而拆分一个故事。如果可以把它分成更小的工作，并且仍然可用，团队应该已经在Backlog Refine里做到了这一点。团队专注于结果 Outcomes（价值），而不是产出Outputs（已完成的工作）。

2. 代码腐烂 Code rots

敏捷团队跨职能、自组织，团队所有成员共同拥有代码库，这使得代码库很可能在一周内发生很大变化。那么这个建议"开发已经完成了，我们可以关掉这个用户故事，然后创建一个测试的故事"，很有可能造成不可预期的结果。团队成员需要基于最新的代库，更新甚至重做上个Sprint"已经完成的工作"。

3. 不要偷工减料

这与代码腐烂密切相关。如果在当前Sprint里存在没有完成的工作，团队应该将跟它相关的所有任务（包含已经完成的和未完成的）设置为To Do，并且将它们返回到产品待办列表中。

当在下个 Sprint 重新开始该项工作时，团队需要再次验证所有的任务，确保没有遗漏任何东西，以此来确保高质量交付。

4. 高估和低估的数量最终会达到平衡

这个主要适用于“这个用户故事我们评估的太少，应该增加到13点"和“在上个Sprint团队已经完成了90%，下个Sprint只需要1个故事点就够了，应该减少到1个点"，从长远来看，一切都是平衡的。

敏捷是经验性过程，从长远来看，敏捷团队会最终达成一个平衡，当然这是建立在稳定的团队的基础之上。

检视和调整

当出现未完成工作的时候，借此机会提出一个问题，"我们是否应该继续做这项工作？"每个Sprint都是一个检视和调整的机会。其中一部分工作是查看产品待办列表里的所有内容，并询问"这是否仍然支持产品目标？"

作者：Joel Bancorft-Connors

译者：Jerry Yang

原文链接：https://resources.scrumalliance.org/Article/re-estimate-unfinished-stories