评估迭代计划的准确性，核心是把迭代开始时承诺的范围与迭代结束时实际交付的范围放在同一口径下比较。常用三个指标：承诺达成率、计划变更率、范围偏差率。三者需要配套时间窗、计数单位和缺失值规则一起看，单看一个指标容易误判。下文给出可复算的定义、取数口径、计算步骤和一个完整算例。
要点总览（TL;DR）
- 评估迭代计划准确性，是把迭代开始时冻结的承诺范围与迭代结束时的实际交付结果放在同一口径下比较，回答“说好的事做完了多少、范围改了多少”。
- 承诺达成率＝迭代内按计划完成并验收通过的承诺项数÷迭代开始时承诺项数；计划变更率＝迭代期间新增、移除、替换的承诺项数÷迭代开始时承诺项数；范围偏差率＝（结束时范围−开始时范围）÷开始时范围。
- 三个指标共用同一计数单位（工作项数或故事点）和同一时间窗（迭代开始冻结时点至迭代结束验收时点），分母为零时标注缺失，不记为0或100%。
- 解读要组合看：高达成率可能来自保守承诺，变更率高低需结合变更原因，未完成项在下一迭代重新评估而非默认结转。
- 指标用于改进估算、需求拆分和验收前置等计划方法，单次迭代结果不宜直接对应个人绩效。
评估目标：判断计划“准不准”到底在判断什么
迭代计划准确性评估的对象，是迭代开始时团队承诺的范围与迭代结束时实际交付结果之间的一致性。它回答的问题是：当初说好要做的事，最后按约定做完了多少；过程中范围被改动了多少；结束时的范围相对开始时偏移了多少。评估的起点是承诺，终点是验收，中间的变化需要被记录和解释。
这个判断需要与另外两类问题分开。第一类是团队产能问题，关注单位时间内能完成多少工作，通常用吞吐量、速率等指标衡量；计划准确性不评价产能高低，只评价承诺与交付的匹配程度。第二类是需求价值问题，关注做的事情是否值得做，属于优先级和产品决策范畴；一个迭代可能计划准确但方向错误，也可能计划偏差较大但交付了更有价值的内容。三类问题使用不同数据、回答不同问题，混在一起会导致结论失真。
评估结果的使用方式也需要事先约定。指标适合用于改进计划方法：调整估算习惯、优化需求拆分粒度、识别插入需求的来源、改善验收前置条件。将单次迭代的达成率直接对应到个人考核，会诱导保守承诺和规避变更，反而破坏计划信息的真实性。若组织确实需要绩效关联，应使用多迭代趋势和团队层面的组合指标，并明确说明使用边界。
指标与范围：承诺达成率、计划变更率等怎么定义
三个指标共用同一套计数基础和时间窗，才能相互印证。计数单位需要在评估周期内固定：按工作项数计数适合颗粒度较均匀的团队，按故事点计数适合估算体系稳定的团队，两者不可在同一指标中混用。时间窗以迭代开始冻结承诺范围的时点为起点，以迭代结束验收完成的时点为终点，两端定义一致才可跨迭代比较。
| 指标名 | 公式 | 分子 | 分母 | 时间窗 | 单位 |
|---|---|---|---|---|---|
| 承诺达成率 | 迭代内按计划完成并验收通过的承诺项数 ÷ 迭代开始时承诺项数 | 迭代开始时在承诺范围内、迭代结束前完成且验收通过的工作项 | 迭代开始时冻结的承诺工作项总数 | 迭代开始冻结时点至迭代结束验收时点 | 工作项数或故事点，全周期统一 |
| 计划变更率 | 迭代期间新增、移除或替换的承诺项数 ÷ 迭代开始时承诺项数 | 迭代期间发生的新增项、移除项、替换项之和 | 迭代开始时冻结的承诺工作项总数 | 迭代开始冻结时点至迭代结束验收时点 | 工作项数或故事点，全周期统一 |
| 范围偏差率 | （迭代结束时范围 − 迭代开始时范围）÷ 迭代开始时范围 | 结束时范围与开始时范围之差 | 迭代开始时冻结的承诺工作项总数 | 迭代开始冻结时点至迭代结束验收时点 | 工作项数或故事点，全周期统一 |
新增、移除、替换需要事先界定并逐条记录。新增指迭代开始后进入承诺范围的工作项；移除指原承诺范围内被移出迭代的工作项；替换指移除一项并加入另一项，按一项移除加一项新增计数，或按替换单独计数，规则需在评估前固定，避免同一变更在不同迭代中被重复或遗漏统计。变更原因也应同步记录，如需求插入、估算修正、依赖阻塞、验收标准调整，供后续归因使用。
未完成项的处理规则要明确：迭代结束时未完成且未验收通过的承诺项，不计入承诺达成率的分子，同时保留在分母中；这些工作项在下一迭代需要重新评估优先级与估算，不默认自动结转。范围偏差率中的结束时范围，按迭代结束时的实际承诺范围计算，已移除项不计入，新增项计入。
缺失值与分母为零需要单独规定。迭代开始时承诺项数为零时，三个指标均不适用，应标注为缺失而不是记为0或100%，否则会拉偏趋势统计。验收记录缺失的工作项，不能默认视为完成，应标注为待确认并单独列出，待确认项不计入达成率的分子。跨迭代汇总时，建议按项数加权汇总，而不是对每迭代比率取简单平均。
数据口径与证据：从哪里取数、如何保证可比
取数来源主要有三类：迭代范围快照、工作项状态流转记录、验收记录。范围快照提供迭代开始时的承诺清单，是三个指标共同的分母来源；状态流转记录提供每项工作在迭代期间的状态变化与完成时点；验收记录提供“完成并验收通过”的证据，缺少验收记录时完成状态不足以支撑达成率计算。
迭代开始快照的留存方式决定指标能否复算。可行做法是在迭代计划会议结束、范围确认后，导出承诺工作项清单，记录工作项标识、标题、估算值、负责人和冻结时间，作为该迭代的基线文件存档。迭代期间的范围变化逐条登记，注明变更类型、时间和原因。没有基线快照，计划变更率和范围偏差率只能事后回忆，数据可信度会明显下降。
跨迭代比较前需要对齐若干前置条件：计数单位一致；迭代周期长度相近或已做归一化说明；验收标准严格程度一致；团队构成和业务类型没有发生结构性变化。条件不一致时，指标可以各自呈现，但不宜直接排名或画同一条趋势线。评估前建议做一次校验：抽查若干工作项的完成时点是否落在迭代时间窗内、验收记录是否齐全、变更登记是否与快照差异吻合。
在工具层面，ONES 敏捷研发管理覆盖迭代规划、迭代开发、迭代进度跟进和迭代回顾等场景。产品负责人可按优先级将需求规划至对应迭代，团队在计划会议上对需求与验收标准达成一致，并用子任务拆分需求以便跟踪；迭代过程中通过敏捷看板管理任务状态，迭代结束后可借助燃尽图、工时日志等报表复盘进度与偏差。这些记录为范围快照、状态流转和验收证据提供了取数基础。若需要将承诺达成率、计划变更率固化为可配置的报表指标，建议在选型或实施时核验报表的自定义计算能力与快照留存方式。
计算与评估步骤：从取数到得出结论
按以下步骤执行，可以在一个迭代内完成一次完整评估，并让结果可被他人复算。
- 冻结承诺范围。在迭代计划会议结束、范围确认后，导出承诺工作项清单并记录冻结时间，形成基线快照。完成标志是快照文件可被独立查阅，且包含计数单位所需的估算值。
- 登记范围变更。迭代期间每发生一次新增、移除或替换，即时登记工作项、变更类型、时间和原因。完成标志是变更清单与快照的差异可以逐条对应。
- 统计完成与验收。迭代结束时，按同一计数单位统计承诺范围内完成且验收通过的工作项，同时列出未完成项和待确认项。完成标志是每项完成状态都有验收记录支撑。
- 计算三项指标。按定义表代入分子分母，分别计算承诺达成率、计划变更率、范围偏差率；分母为零时标注缺失。完成标志是计算过程留有中间数据，他人可复算。
- 对偏差做归因。将未达成和变更按原因分类：估算偏差、需求插入、依赖阻塞、验收未通过、范围移除。完成标志是每类原因有对应的项数和占比。
- 形成下一迭代的计划调整动作。针对占比最高的原因提出具体动作，例如调整估算校准方式、设置需求插入的准入条件、提前澄清验收标准、拆分过大的工作项。完成标志是动作有负责人和可观察的检查点。
归因环节决定指标是否有用。承诺达成率偏低但计划变更率也低，通常指向估算偏差或阻塞；承诺达成率偏低且计划变更率高，通常指向需求插入或范围管理问题；范围偏差率接近零但变更率较高，说明新增与移除相互抵消，范围总量稳定但内容已大幅替换，需要结合变更原因判断是否影响交付价值。
例子：一个迭代的完整算例
以下为演示情景，数字仅用于说明计算过程，不代表任何团队的实际水平。某迭代开始时冻结承诺工作项20项，迭代期间新增3项、移除2项、替换1项（按一项移除加一项新增计数，则替换贡献移除1项、新增1项），迭代结束时承诺范围内完成并验收通过14项，未完成4项，待确认2项。
| 指标 | 计算过程 | 结果 |
|---|---|---|
| 承诺达成率 | 14 ÷ 20 | 70% |
| 计划变更率 | （新增3 + 移除2 + 替换计新增1与移除1）÷ 20 = 6 ÷ 20 | 30% |
| 范围偏差率 | 结束时范围 = 20 + 3 + 1 − 2 − 1 = 21；（21 − 20）÷ 20 | 5% |
解读这组结果需要把三个指标放在一起。承诺达成率70%说明承诺项中有三成未按计划完成并验收；计划变更率30%说明迭代期间范围改动较多；范围偏差率仅5%说明新增与移除大体抵消，范围总量变化不大。综合来看，问题更可能出在范围内容替换和验收环节，而不是范围总量失控。待确认2项需要先补齐验收记录，再判断是否计入完成；若这2项最终验收通过，承诺达成率将变为80%。
分母为零的情形单独处理：若某迭代开始时承诺项数为零，三项指标均标注缺失，不参与趋势汇总。全部未完成的情形下，承诺达成率为0%，计划变更率与范围偏差率仍按公式计算，但解读时需说明该迭代是否属于探索性工作，避免把探索性迭代与常规交付迭代直接比较。
解读与限制：指标能说明什么、不能说明什么
承诺达成率高，可能来自计划执行到位，也可能来自承诺过于保守。判断时需要结合历史趋势和范围偏差率：达成率长期接近100%且范围偏差率接近零，可能说明计划留有余量，可以适度提高承诺难度；达成率波动较大且变更率较高，则更可能指向计划方法不稳定。低达成率同样需要区分原因，探索性工作或外部依赖较多的迭代，达成率偏低可能是合理结果，关键看偏差是否被识别和解释。
计划变更率的高低要结合变更原因判断。需求插入带来的变更可能反映业务响应能力，也可能反映需求准入缺失；估算修正带来的变更更多指向估算方法；移除项可能来自优先级重排。把变更率当作越低越好的指标，会压制合理的范围调整，导致团队在计划阶段过度保守或隐瞒变更。
未完成工作需要在下一迭代重新评估优先级与估算，不默认自动结转。自动结转会让承诺范围持续膨胀，使后续迭代的达成率被历史欠账拖累，也会掩盖真实的计划能力。指标的使用目的是改进计划方法，包括估算校准、需求拆分粒度、验收标准前置和变更准入规则，不宜直接作为个人绩效考核依据。单次迭代的指标受偶发因素影响较大，建议以连续多个迭代的趋势和归因结论作为改进依据。
常见问题
迭代开始时没有留存范围快照，还能补算计划变更率和范围偏差率吗？
可以补算，但可信度会下降。缺少基线快照时，只能依赖工作项的创建时间、状态流转记录和变更日志回溯迭代开始时的承诺清单，再逐条比对迭代期间的新增、移除和替换。补算时应把回溯方式和不确定项标注出来，例如无法确认创建时点的工作项单独列出，不强行归入分子或分母。
更稳妥的做法是从下一个迭代起固定留存快照：计划会议结束、范围确认后导出承诺工作项清单，记录标识、估算值、负责人和冻结时间并归档。有了基线，后续迭代的变更率和偏差率才能稳定复算和横向比较。
团队按故事点估算，但部分工作项没有估点，指标该怎么算？
先确定缺失估点的处理规则，并在评估前固定下来。常见做法有两种：一是对缺失估点的工作项在评估前补齐估算，再按故事点统一计算；二是将这类工作项单独列出，按项数口径补充说明，不混入故事点口径的分子分母。
无论选哪种，同一评估周期内只能使用一种计数单位，工作项数和故事点不能在同一指标中混用。若缺失估点的比例较高，说明估算流程本身需要改进，可把“计划会议前完成估点”作为下一迭代的计划调整动作之一。
承诺达成率连续几个迭代都很低，应该先查什么？
先做归因，再谈调整。把未达成项按原因分类：估算偏差、需求插入、依赖阻塞、验收未通过、范围移除，统计各类的项数和占比。若估算偏差占比最高，优先校准估算方式和历史参考数据；若需求插入占比最高，优先建立需求进入迭代的准入条件；若验收未通过占比高，则把验收标准的澄清提前到计划阶段。
同时对照计划变更率：达成率低且变更率也低，通常指向估算或阻塞问题；达成率低且变更率高，更可能是范围管理问题。归因结论应落到具体动作，并指定负责人和检查点，避免只停留在“下个迭代注意”这类笼统表述。
迭代中临时插入紧急需求，算不算计划不准确？
算范围变更，但不等同于计划方法有问题。紧急需求插入属于计划变更率统计中的新增项，应逐条登记工作项、插入时间和原因。解读时要把这类变更与估算修正、范围移除区分开：前者反映业务响应，后者更多反映计划质量。
如果插入频繁且集中在迭代中后期，可以评估是否需要设置插入准入条件，例如明确插入的审批人、可占用的缓冲比例，或把部分容量预留给计划外工作。这样既保留响应能力，也让承诺范围与可用容量更匹配。
这些指标能否直接用于团队或个人绩效考核？
不建议直接使用。承诺达成率和计划变更率一旦与个人考核挂钩，容易诱导保守承诺、隐瞒变更或压低承诺范围，指标反映的信息会失真，反而削弱计划改进的基础。
更合适的用法是把指标作为团队层面的过程改进输入：看连续多个迭代的趋势，结合归因结论调整估算校准、需求拆分粒度和验收前置等做法。若组织确需与绩效关联，应使用多迭代趋势和团队组合指标，并事先说明使用边界和例外情形。
