• 敏捷领导力(CAL E+T+O)认证在线培训
  • Coaching Agile Teams 在线工作坊
  • 测试驱动开发(TDD)在线练功房
  • Single_work_0519
  • Five_reasons
  • Hardware-agile-practice
  • Clp_20220108
  • A-CSM 国际Scrum联盟认证 ScrumMaster
  • 数字时代下的敏捷领导力
  • 汽车行业敏捷开发课程
  • CSM A-CSM一站式培训
  • CSM CSP CAL CSPO CSD CST CEC CTC
  • Scrum敏捷培训 Scrum敏捷企业内训
如何重新评估未完成的工作

当团队没有在当前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