Azure Boards存在部分完成工作项时正确关闭Scrum Sprint的方法

核心目标 #

处置过程需严格匹配 Azure Boards 的内置度量计算逻辑，避免团队速率、燃尽图、周期时间等核心统计指标出现偏差，保证Sprint交付价值核算的真实性。

分步骤标准化操作流程 #

• 开展Sprint收尾前盘点
  在Sprint正式结束前1-2天，拉取当前迭代下所有状态为“待办”“进行中”的用户故事、关联任务，逐一核对实际交付完成度，严禁为拉高Sprint完成率随意将部分完成的工作项标记为全量完成。
• 拆分未完成工作的价值边界
  对部分完成的工作项，首先将已经100%交付、可独立验证的子项标记为已完成，匹配对应的实际工作量；对尚未交付的剩余范围，重新核定实际需要投入的剩余工作量（剩余小时数、对应拆分后的故事点），避免沿用原工作项预设的全量工作量数值。
• 规范跨Sprint工作项流转
  结合Azure Boards 内置的指标计算规则，按以下要求完成流转，从根源上避免统计失真：
  • 将所有未完成的工作项从当前即将关闭的Sprint迭代路径移出，要么创建独立的新工作项承接剩余未交付范围，要么直接调整原未完成项的迭代路径到下一个规划中的Sprint
  • 同步重置对应工作项的剩余工作量字段为核定后的实际值，清空之前残留的不匹配的完成百分比数据
  • 注意不要等Sprint完全关闭后再补移动未完成的工作项，否则系统会自动把工作项的创建、启动时间记录在旧Sprint的统计区间，直接造成跨Sprint的指标错配
  • 确保Sprint正式关闭时，该迭代路径下不存在任何处于非终态（进行中、待办、已启动）的工作项，所有遗留未完成工作均有明确的后续迭代归属
• Sprint关闭前的度量校验
  核对三个核心统计口径，避免偏差：
  • 已结束Sprint的总承诺工作量与实际纳入该迭代的工作项工作量匹配
  • 该迭代下标记为完成的工作项总价值，与团队实际可交付的验证成果完全对应
  • 跨Sprint带来的未完成工作，已在下一次Sprint规划中明确纳入承诺范围，无无归属的悬空工作项

官方规则核心说明 #

Azure Boards 内置Scrum模板的设计逻辑中，团队速率、燃尽图等指标的计算完全基于工作项的迭代归属路径、状态变更时间戳统计；若将未完成工作项遗留在历史已关闭的Sprint中，后续完成时会出现“工作量计入旧Sprint、完成值计入新Sprint”的统计错配，直接导致指标失真。

内容的提问来源于stack exchange，提问作者Gary Barrett