衡量迭代目标达成情况，常用的是一组互补指标：承诺完成率、目标达成率、范围变更率、计划偏差和质量返工率。单看完成率容易被范围调整和质量欠账掩盖，因此需要先固定分母、时间窗和完成定义，再结合未达成原因分类解读。本文的评估范围限于单个迭代运行，用于复盘改进，不用于绩效排名。
要点总览（TL;DR）
- 衡量迭代目标达成情况，用承诺完成率、目标达成率、范围变更率、计划偏差和质量返工率五类指标组合判断，覆盖目标、范围、进度和质量四个侧面。
- 统计前先固定分母、时间窗和完成定义：承诺完成率的分母取迭代开始时的承诺项，统计截止到迭代结束日，验收未通过按未完成计。
- 判定按顺序进行：先看目标达成率，再看承诺完成率，然后用范围变更率和质量返工率判断完成率是否被范围调整或质量欠账掩盖，最后看计划偏差。
- 单指标存在盲区，承诺完成率可通过缩减承诺变高，目标达成率可能因目标宽泛虚高，需结合未达成项的归因分类解读。
- 未完成工作应重新评估价值、优先级和拆分方式后再决定是否进入下一迭代，默认自动结转会让承诺完成率失去意义。
评估目标：先明确“达成”指什么
迭代目标通常写在迭代说明里，例如“完成订单结算流程改造并上线灰度”。承诺工作项则是团队在迭代计划会上纳入本次迭代的需求、任务和缺陷。两者相关但不重合：目标描述要取得的业务或交付结果，承诺工作项是支撑该结果的具体工作。评估时要分别判定，避免用“工作项都关了”直接替代“目标实现了”。
把“达成”转为可判定的评估对象，需要回答三个问题：
- 目标是否实现：迭代目标中描述的结果是否发生，例如功能是否上线、灰度是否覆盖约定范围、验收是否通过。
- 承诺是否交付：迭代开始时承诺的工作项，在迭代结束时按约定完成定义交付了多少。
- 质量是否可接受：交付内容是否在迭代内产生返工、缺陷或验收不通过，导致实际可用性下降。
这三个问题对应目标层与承诺层两层判定对象。目标层看结果，承诺层看交付范围，质量层看交付是否站得住。评估结果主要用于迭代复盘：哪些判断准确、哪些估算偏差、哪些依赖没有提前处理。把它直接用于个人或团队绩效排名，会诱导缩小承诺范围或降低完成标准，反而破坏指标的可比性。
指标与范围：五类核心指标及适用边界
五类指标各自回答一个评估问题，组合使用才能覆盖目标、范围、进度和质量四个侧面。下表给出定义与适用边界。
| 指标 | 定义 | 回答的问题 | 适用边界 |
|---|---|---|---|
| 承诺完成率 | 已完成承诺项数 ÷ 承诺项总数 | 迭代开始时承诺的工作交付了多少 | 依赖完成定义和分母口径；不反映目标价值 |
| 目标达成率 | 已达成目标项数 ÷ 目标项总数 | 迭代目标实现了多少 | 目标项需可判定；目标模糊时结果不可比 |
| 范围变更率 | 迭代内新增或移除项数 ÷ 初始承诺项数 | 承诺范围在迭代中变动多大 | 需结合变更原因；合理变更与范围蔓延要区分 |
| 计划偏差 | 实际完成时间或工作量 ÷ 计划值 | 实际投入与计划相差多少 | 需要统一的估算单位；估算本身有误差 |
| 质量返工率 | 返工项或缺陷数 ÷ 交付项数 | 交付内容在迭代内返工多少 | 依赖缺陷记录完整性；跨团队缺陷口径可能不同 |
组合使用的原因在于单指标存在盲区。承诺完成率可以通过缩减承诺或把未完成项移出迭代而变高；目标达成率可能因目标写得宽泛而虚高；计划偏差小也可能来自估算放水。范围变更率和质量返工率分别从范围和质量两侧补位，让“完成”更接近真实交付。
这组指标不覆盖团队能力评价、跨迭代长期价值、客户满意度等内容。它们描述的是单个迭代的运行结果，不能直接推导人员能力高低，也不能替代产品价值评估。
数据口径：分母、时间窗与完成定义
同一迭代在不同口径下会得出不同结论，统计前需要先对齐以下约定。
- 分母选择：承诺完成率的分母取迭代开始时确认的承诺项，迭代内新增项单独计入范围变更，不混入原分母；如需看全量交付，可另算“全量完成率”，但需标注口径。
- 时间窗：以迭代起止日为准，统计截止时点固定为迭代结束日当天结束。迭代结束后补做的验收或修复，计入下一迭代或单独标注，不回溯修改本期结果。
- 完成定义：工作项达到团队约定的完成状态才计入完成，例如开发完成且验收通过。验收未通过、仅提测或仅合并代码的，按未完成计。完成定义应在迭代开始前写入团队约定。
- 缺失值处理：工作项缺少估算值、缺陷记录不完整或状态未及时更新时，先补录再统计；无法补录的，在结果中标注“数据不完整”，不默认按完成或未完成处理。
- 分母为零：承诺项为零时，承诺完成率不计算，标注“无承诺项”；目标项为零时，目标达成率不计算，改为说明本期无明确迭代目标。不要用0%或100%代替无数据。
这些约定建议在迭代计划会结束时确认一次，复盘时直接复用。口径一旦固定，跨迭代趋势才有比较基础。
计算与评估步骤：从取数到判定
各指标的计算公式如下，分子分母均限定在同一迭代时间窗内。
| 指标 | 公式 | 单位 |
|---|---|---|
| 承诺完成率 | 已完成承诺项数 ÷ 初始承诺项数 × 100% | 百分比 |
| 目标达成率 | 已达成目标项数 ÷ 目标项总数 × 100% | 百分比 |
| 范围变更率 | （迭代内新增项数 + 移除项数）÷ 初始承诺项数 × 100% | 百分比 |
| 计划偏差 | 实际完成工作量 ÷ 计划工作量（或实际完成时间 ÷ 计划时间） | 比值，1.0为持平 |
| 质量返工率 | 返工项或缺陷数 ÷ 交付项数 × 100% | 百分比 |
目标达成率的加权方式有两种：按目标项等权，每个目标算1分，适合目标数量少、重要性接近的迭代；按价值权重，给每个目标分配权重后加权求和，适合目标重要性差异明显的迭代。权重需在迭代开始时确定，复盘时不再调整。
判定流程建议按以下顺序进行：
- 先看目标达成率，确认迭代目标中哪些实现、哪些未实现。
- 再看承诺完成率，确认承诺工作项的交付比例。
- 然后看范围变更率和质量返工率，判断完成率是否受范围调整或质量欠账影响。
- 最后看计划偏差，判断估算和排期是否准确。
- 对未达成项做归因分类：需求变更、估算偏差、依赖阻塞、质量返工，每项归入一类并记录依据。
归因分类是解读的关键。同样是承诺完成率80%，因需求变更移出两项与因依赖阻塞延期两项，改进动作完全不同。归因结果应写入复盘记录，作为下一迭代调整承诺和排期的输入。
示例：一个迭代的达成情况计算
以下为演示情景，数据为虚构，仅用于说明计算过程。
某迭代初始承诺10个工作项，对应3个迭代目标；迭代结束时完成7个承诺项，达成2个目标；迭代内新增2项、移除1项；交付7项中有2项在迭代内返工；计划工作量40人时，实际完成46人时。
| 指标 | 计算 | 结果 |
|---|---|---|
| 承诺完成率 | 7 ÷ 10 | 70% |
| 目标达成率（等权） | 2 ÷ 3 | 66.7% |
| 范围变更率 | (2 + 1) ÷ 10 | 30% |
| 计划偏差 | 46 ÷ 40 | 1.15 |
| 质量返工率 | 2 ÷ 7 | 28.6% |
若改用“迭代结束时全部项”作分母，承诺完成率变为7 ÷ 11 ≈ 63.6%，因为新增2项、移除1项后总数为11。两种口径差异明显，说明分母必须在统计前固定并注明。
解读这份结果：目标达成率66.7%，有一个目标未实现；承诺完成率70%，范围变更率30%说明本期范围调整较大，需核对新增项是否属于紧急插入、移除项是否因优先级下调；计划偏差1.15表示实际投入超出计划15%，结合返工率28.6%看，部分超支可能来自返工。归因上，未完成的3个承诺项中，1项因需求变更移出、1项因外部依赖阻塞、1项因返工占用时间，改进动作分别对应变更评审、依赖提前确认和验收标准前置。
解读与限制：指标能说明什么、不能说明什么
完成率高不等于目标价值实现。工作项全部关闭，迭代目标描述的业务结果仍可能没有发生，例如功能上线但使用量未达预期。目标达成率需要配合目标本身的判定标准使用，目标写得越具体，结果越可信。
范围变更率要结合变更原因判断。迭代内因紧急线上问题插入工作是合理的，因需求方临时加需求则可能是范围蔓延。把变更率一律视为负面，会掩盖真实的优先级调整；一律视为正常，则失去约束作用。
这组指标适合同一团队跨迭代的趋势对比，不适合跨团队直接排名。不同团队的迭代长度、工作项粒度、缺陷记录习惯不同，直接比较会得出误导性结论。若要横向参考，需先对齐口径并说明差异。
未完成工作的处理应重新评估，而非默认自动结转到下一迭代。结转前要确认该项是否仍有价值、优先级是否变化、是否拆分。默认结转会让承诺完成率失去意义，也会让下一迭代的承诺范围虚高。
指标体系本身需要定期调整。建议每季度回顾一次：哪些指标连续多个迭代没有提供有效信息，哪些口径反复产生争议，哪些归因分类需要细化。调整时保留历史口径说明，避免趋势线断裂。
在工具层面，迭代目标、承诺工作项、完成状态和缺陷记录需要有统一的承载位置，统计时才能按固定口径取数。ONES 的迭代管理与工作项状态配置可以承载承诺范围、完成定义和缺陷记录，使上述指标在同一数据源上复算；具体字段和流程按团队约定配置。
常见问题
迭代目标写得比较宽泛，目标达成率还能用吗？
可以用，但结果的可信度取决于目标是否可判定。目标写成“提升用户体验”这类描述，复盘时很难判断是否实现，达成率容易变成主观打分。建议在迭代计划阶段把目标改写成可观察的结果，例如“结算流程灰度覆盖约定范围并通过验收”，再按目标项统计达成情况。目标本身模糊时，达成率更适合作为讨论起点，不宜直接当作结论。
迭代中途插入紧急需求，范围变更率升高是否说明迭代管理有问题？
不一定。范围变更率只反映变动幅度，合理性要结合变更原因判断。因线上故障、监管要求等紧急事项插入工作，属于优先级调整；因需求方临时加需求、缺少变更评审而插入，更接近范围蔓延。建议在记录变更时同步标注原因和决策人，复盘时区分两类情况，再决定改进动作是加强变更评审还是调整承诺预留。
同一组数据，用初始承诺项和迭代结束时全部项作分母，结论差异很大，应该用哪个？
两个口径回答的问题不同。承诺完成率用初始承诺项作分母，衡量团队对期初承诺的兑现程度；用迭代结束时全部项作分母，衡量本期实际交付占最终范围的比例。评估目标达成情况时，建议以初始承诺项为主口径，把新增项单独计入范围变更率，避免范围调整稀释承诺兑现情况。若需要看全量交付，可另算一个指标并注明口径，两个结果并列呈现，不混用。
迭代结束后补做的验收和修复，应该算进本期还是下一期？
按固定时间窗处理：统计截止时点设为迭代结束日当天结束，之后补做的验收或修复计入下一迭代或单独标注，不回溯修改本期结果。这样做的目的是保证同一迭代的结果可复算，跨迭代趋势可比。如果验收周期本身较长，可以在完成定义中提前约定“验收通过才算完成”，并在迭代计划时预留验收时间，减少期末集中补做的情况。
这组指标能不能用来比较不同团队的表现？
不建议直接横向排名。不同团队的迭代长度、工作项粒度、缺陷记录习惯和完成定义可能不同，直接比较会得出误导性结论。这组指标更适合同一团队跨迭代的趋势对比，观察承诺兑现、范围稳定性和返工情况的变化。若确实需要横向参考，先对齐分母、时间窗和完成定义，并在结果旁说明口径差异，把比较限定在方法讨论层面。
