每日站会后或迭代中期，团队常被问“现在完成多少了”，任务完成率往往成为最顺手的回答。它能说明已关闭任务占计划任务的比例，却难以回答进展是否真实：剩余工作是否在减少、阻塞是否在拖长、已完成的任务是否真正达到完成定义。本文围绕具体迭代的运行状态，给出完成率的计算口径、需要补充观察的过程信号，以及一套可复算的评估步骤。
要点总览（TL;DR）
- 任务完成率按“已完成任务数÷计划任务数”计算，任务粒度不等会让低权重任务拉高完成率，完成定义未核对也会让“完成”高估真实进展。
- 判断迭代进展应补充三类过程信号：按故事点或工时记录的剩余工作量趋势、从标记到解除的阻塞持续天数、评审测试文档等完成定义条目的逐项核对结果。
- 评估时对比最近三到五日的趋势而非单点数值，识别完成率上升但剩余工作量走平的停滞，以及剩余工作量回升的反弹。
- 未完成工作应逐项重新评估去向，默认结转到下个迭代会把未经确认的工作量带入新计划，并掩盖本迭代的范围与估算问题。
- 完成率反映任务数量进度，需与延期、缺陷率、返工数量组合解读；分母为零时说明计划任务为空，不做比率计算。
评估目标：站会后要判断的是进展真实性
这里评估的对象是一个具体迭代在某一时点的运行状态，包括计划内任务的完成情况、剩余工作的变化趋势、阻塞的持续时间和完成定义的达成程度。判断目标是进展真实性：团队是否在按计划推进，已宣布完成的部分是否可靠，剩余工作能否在迭代结束前收敛。
评估时点有两个典型场景。一是每日站会后，团队刚同步完各自进展，此时适合用当天更新后的数据核对完成率与剩余工作量是否一致；二是迭代中期，通常指迭代周期过半时，此时需要判断后半程的工作量是否可控，是否需要调整范围或处理阻塞。这两个时点的共同点是数据刚更新、问题还来得及处理。
需要明确的是，这套评估用于判断迭代运行状态，不用于给团队成员排绩效名次。任务完成率按任务数量统计，任务拆分粗细由团队自行决定，把它当作个人比较依据会放大任务粒度差异带来的失真。评估结论应落到迭代范围、阻塞处理和后续动作上。
任务完成率的计算口径与三个盲区
任务完成率的公式为：已完成任务数 ÷ 计划任务数 × 100%。分子是统计时点处于完成状态的任务数，分母是迭代计划内纳入本次迭代的任务总数，统计时间窗与迭代周期一致，通常在站会后按当日数据计算。单位是百分比，保留整数或一位小数即可，精度过高没有实际意义。
这个公式简单，但作为进展判断依据存在三个盲区。
第一，任务粒度不等导致权重失真。一个任务可能是一行文案修改，也可能是三天的接口联调，两者在完成率中权重相同。当完成集中在低权重任务上时，完成率会显得乐观，实际剩余工作量并未同步下降。
第二，完成定义未达成也计入完成的风险。如果任务只要开发改完状态就被标记完成，评审、测试、文档等条目尚未核对，完成率会高估真实进展。这类“完成”在迭代后期往往返工，形成进度反弹。
第三，迭代中期完成率天然偏低，不能直接外推。迭代前几日通常在做需求澄清、方案设计等前置工作，任务关闭集中在后半段。用第3天或第5天的完成率线性推算迭代结束时的完成情况，容易得出过于悲观的结论，也容易掩盖真实的停滞。
应补充观察的过程信号与数据口径
要判断进展真实性，需要在完成率之外补充三类过程信号，并约定统一的取数口径。下表给出字段、记录方式和更新时点，团队可按自身习惯调整计量单位，但同一迭代内应保持一致。
| 信号 | 字段与口径 | 记录方式 | 更新时点 |
|---|---|---|---|
| 剩余工作量 | 按故事点或工时记录每日剩余值，单位与估算口径一致 | 每日站会后更新剩余值，形成燃尽趋势 | 站会后当日 |
| 阻塞持续时间 | 从任务被标记为阻塞到解除阻塞的时长，按天计 | 阻塞清单记录任务、阻塞原因、标记日期、解除日期 | 站会后当日，解除时即时更新 |
| 完成定义达成情况 | 按评审、测试、文档等条目逐项核对，记录已核对条目数 | 任务完成前逐项勾选，未核对不计入完成 | 任务关闭前 |
剩余工作量建议按故事点或工时记录，而不是按任务个数，这样能部分抵消任务粒度差异。燃尽趋势看的是每日剩余值连成的曲线，单日数值波动不必过度解读，连续两三天走平或上升才值得追问。
阻塞持续时间按天计，重点是识别持续多日的阻塞。一个阻塞持续三天以上，通常意味着依赖方未响应或问题超出团队处理范围，应单独列入风险跟踪，而不是等它自然解除。
完成定义达成情况需要逐项核对。评审是否通过、测试是否执行、文档是否更新，这些条目在任务关闭前完成核对，完成率才具备可信度。核对记录本身也是迭代回顾时的证据。
在工具承载上，ONES 的敏捷看板可用于站会中对齐任务状态与风险，燃尽图可观察剩余工作的变化趋势，任务工时统计可辅助估算任务持续时间。团队把站会后更新剩余值、登记阻塞清单、关闭前核对完成定义这几步固定下来，完成率与过程信号就能在同一套工作项数据上对照查看。
评估步骤：从取数到判断进展
以下步骤可在站会后或迭代中期执行，每一步都有明确产物，便于复算和交接。
- 确定迭代范围与计划任务清单。导出本次迭代计划内的全部任务，确认分母口径，排除迭代中途临时插入但未纳入计划的任务，或将其单独标注。产物是一份带任务编号和估算值的清单。
- 按日取完成率、剩余工作量、阻塞清单。完成率按当日完成状态计算，剩余工作量取当日站会后更新的剩余值，阻塞清单记录当前未解除的阻塞及其已持续天数。产物是当日的三项数据。
- 核对完成定义达成条目。对已标记完成的任务抽查或全查评审、测试、文档等条目，记录未核对即关闭的任务数量。产物是完成定义核对结果。
- 对比趋势而非单点数值。把最近三到五日的完成率与剩余工作量放在一起看，识别停滞（完成率上升但剩余工作量不降）或反弹（剩余工作量回升）。产物是一段趋势判断，而不是一个百分比。
- 对未完成工作重新评估，不默认结转。逐项判断未完成任务是继续留在本迭代、拆小后继续、退回待办还是取消，重新估算剩余工作并调整计划。产物是更新后的迭代范围与处理决定。
这五步的关键在于第四步和第五步。趋势对比把单点数字变成方向判断，重新评估则避免未完成工作无声地滚入下一个迭代，导致下个迭代一开始就背负隐性债务。
例子：同一完成率下的两种迭代状态
以下为演示情景，用于说明信号组合的判断方式，数据不代表真实项目结论。设定迭代周期10天，计划任务20个，总估算100故事点，第5天两种情形的完成率均为50%。
| 观察项 | 情形A | 情形B |
|---|---|---|
| 第5天完成率 | 50%（完成10个任务） | 50%（完成10个任务） |
| 完成任务的故事点 | 约50点，与任务数比例接近 | 约25点，完成集中在低权重任务 |
| 剩余工作量趋势 | 从100点平稳降至50点 | 从100点降至75点后连续两日走平 |
| 阻塞情况 | 无持续超过1天的阻塞 | 两个阻塞已持续3天，涉及外部依赖 |
| 完成定义核对 | 已完成任务逐项核对通过 | 部分已完成任务未核对测试与文档 |
情形A的判断是进展真实：完成率与剩余工作量同步下降，完成的任务经过核对，后半程按当前速度可以收敛。后续动作是保持节奏，关注剩余任务中是否有高估或低估。
情形B的判断是进展存疑：完成率看似过半，但剩余工作量走平说明实际产出不足，两个持续3天的阻塞正在压缩后半程时间，未核对的完成定义可能带来返工。后续动作是先处理阻塞、明确依赖方响应时间，再对未核对的任务补做核对，并重新评估剩余15个任务能否在5天内完成，必要时缩减范围。两种情形完成率相同，结论和动作完全不同，差别来自过程信号的组合。
解读与限制：指标边界与常见误用
任务完成率反映的是任务数量维度的进度，不反映价值交付与质量。完成十个任务不等于交付了用户可用的功能，也不等于缺陷率可控。把它作为唯一进展依据，容易让团队把注意力放在关闭任务上，而不是把工作做到可交付状态。
分母为零时需要单独处理。当迭代计划任务为空，完成率无法计算，应说明计划任务为空这一事实，而不是记为0%或100%。这种情况下应回到迭代范围本身，确认是否尚未规划或数据未同步。
跨迭代比较需要谨慎。不同迭代的任务粒度、估算习惯和完成定义严格程度可能不同，两个迭代的完成率数值接近，不代表进展质量相同。比较时应同时看剩余工作量口径和完成定义核对情况。
完成率适合与延期情况、缺陷率、返工数量等指标组合使用，形成对进度和质量的交叉验证。任何单一指标都不能作为因果保证，完成率高不必然意味着迭代目标会达成，完成率低也不必然意味着团队产出不足，需要结合阻塞、范围和完成质量一起解读。
最后，未完成工作的处理应经过重新评估。默认自动结转到下一个迭代，会让下个迭代的计划从一开始就包含未经确认的工作量，也会掩盖本迭代范围设定或估算上的问题。重新评估后再决定去向，是让完成率数据保持可信的前提。
常见问题
迭代中期完成率只有40%，是否说明团队进度落后？
不能直接下这个结论。迭代前几日通常在做需求澄清、方案设计等前置工作，任务关闭集中在后半段，中期完成率天然偏低，线性外推容易得出过于悲观的判断。
更可靠的做法是把完成率与剩余工作量趋势放在一起看：如果剩余工作量在平稳下降、没有持续多日的阻塞、已完成任务都通过了完成定义核对，那么40%可能只是节奏分布问题；如果剩余工作量连续几日走平甚至回升，才需要追问范围或阻塞。
任务粒度差异很大时，完成率还能用吗？
可以用，但要配合剩余工作量一起解读。完成率按任务个数统计，一个改文案的任务和三天的接口联调权重相同，完成集中在低权重任务时完成率会显得乐观。
建议剩余工作量按故事点或工时记录，与完成率对照：完成率上升而剩余工作量不降，通常说明关闭的是轻量任务。团队也可以在迭代计划时控制任务拆分粒度，减少单指标失真。
阻塞持续多久需要单独升级处理？
没有统一阈值，但可以设一个团队约定。一个常见做法是阻塞持续三天以上就单独列入风险跟踪，因为这类阻塞往往意味着依赖方未响应或问题超出团队处理范围，等它自然解除会压缩后半程时间。
记录上至少保留任务、阻塞原因、标记日期和解除日期，按天计算持续时长，站会后当日更新，解除时即时更新。这样在迭代中期评估时能直接看到哪些阻塞在拖长。
未完成的任务直接结转到下个迭代有什么问题？
默认结转会让下个迭代的计划从一开始就包含未经确认的工作量，团队在新迭代启动时就背负隐性债务，也会掩盖本迭代范围设定或估算上的问题。
更稳妥的做法是逐项重新评估：继续留在本迭代、拆小后继续、退回待办还是取消，并重新估算剩余工作。重新评估后再决定去向，完成率数据才保持可信。
完成率与燃尽图应该以哪个为准？
两者回答的问题不同，适合交叉验证。完成率反映任务数量维度的关闭比例，燃尽图反映剩余工作随时间的变化趋势。完成率过半但燃尽曲线走平，说明关闭的多是轻量任务，实际产出不足；完成率偏低但燃尽曲线正常下降，可能只是任务关闭动作滞后。
在 ONES 中，敏捷看板可用于站会中对齐任务状态与风险，燃尽图可观察剩余工作的变化趋势，任务工时统计可辅助估算任务持续时间，团队可以把这几项放在同一套工作项数据上对照查看。
