衡量迭代范围调整规则的执行情况，建议从四组指标入手：规则遵守类看变更是否走了约定的评估与审批，范围波动类看新增、移出、替换的工作量占比，例外类看例外次数与原因分布，影响类看范围调整对交付承诺和缺陷的影响。要让这些指标可复算、可比较，前提是统一分母基准和计量单位，通常以迭代启动时确认的范围为分母，按故事点或工作项数量计量。
要点总览（TL;DR）
- 衡量迭代范围调整规则的执行情况，建议用四组指标：规则遵守类（变更申请率、评估审批完成率）、范围波动类（范围变更率、新增/移出/替换占比）、例外类（例外次数、原因分类占比）、影响类（承诺达成率变化、调整后缺陷密度）。
- 统一以迭代启动时确认的范围为分母基准，按故事点或工作项数量计量；未记录原因的变更要单列保留在分母中，分母为零时记为不适用，避免不同迭代之间不可比。
- 计算按五步走：留存基线快照、逐条记录变更类型与审批状态、按公式计算、分单迭代与趋势两个层次解读、结合例外清单做定性复核。
- 解读时先检查记录完整性：低变更率可能是漏记，高遵守率可能是审批流于形式；指标受迭代长度和需求性质影响，宜在同一团队内部看趋势，不宜跨团队硬比。
评估目标：先明确要回答哪几个问题
“衡量执行情况”本身是一个笼统的说法，落到具体迭代上，需要拆成几类可以分别回答的问题。问题不同，取数对象和判断标准也不同，先想清楚要回答什么，后面的指标才有意义。
第一类是规则遵守问题：这个迭代发生的范围变更，是否都经过了约定的评估和审批动作？第二类是范围波动问题：迭代内的范围变动有多大，新增、移出、替换各占多少？第三类是例外处理问题：有多少变更绕过了常规流程，原因是什么，是否被记录和复盘？第四类是交付影响问题：范围调整之后，团队对原承诺的达成情况、缺陷和返工有没有明显变化。
评估对象也要先界定。针对单个迭代，指标用于判断这一次规则执行得怎么样，适合在迭代回顾会上讨论；针对连续多个迭代，指标用于观察趋势，判断规则调整后执行情况是否改善。两种用途对数据完整性的要求不同，单迭代可以容忍少量缺失并做定性补充，趋势分析则要求各迭代口径一致。
还要明确评估结果的用途。如果用于改进规则，重点应放在例外原因分布和规则条款的匹配度上，找出哪些条款难执行、哪些场景缺少约定；如果用于考核团队，则要警惕指标被反向利用，例如团队为了保持低变更率而少报变更、把调整挪到迭代外，反而让数据失真。建议把这类指标作为规则健康度的诊断工具，与例外复盘结合使用。
指标与范围：四组核心指标及适用边界
四组指标分别对应上面四类问题，每组给出名称、公式、单位和分母，形成一张可以复算的指标表。统计范围统一限定在迭代起止时间窗内，纳入统计的工作项类型需要事先约定，例如只统计需求类工作项，或同时纳入任务和缺陷并分列。
| 组别 | 指标 | 公式 | 单位 | 分母 |
|---|---|---|---|---|
| 规则遵守 | 变更申请率 | 有变更申请记录的工作项数 ÷ 发生范围变动的工作项数 | 百分比 | 实际发生变动的工作项数 |
| 规则遵守 | 评估审批完成率 | 完成评估与审批的变更数 ÷ 变更申请总数 | 百分比 | 变更申请总数 |
| 范围波动 | 范围变更率 | （新增 + 移出 + 替换）工作量 ÷ 迭代基线工作量 | 百分比 | 迭代启动基线工作量 |
| 范围波动 | 新增工作量占比 | 迭代内新增工作量 ÷ 基线工作量 | 百分比 | 迭代启动基线工作量 |
| 范围波动 | 移出工作量占比 | 迭代内移出工作量 ÷ 基线工作量 | 百分比 | 迭代启动基线工作量 |
| 范围波动 | 范围替换率 | 替换工作量 ÷ 基线工作量 | 百分比 | 迭代启动基线工作量 |
| 例外 | 例外次数 | 未按常规流程执行的变更次数 | 次 | 不适用 |
| 例外 | 例外原因分类占比 | 某类原因例外数 ÷ 例外总数 | 百分比 | 例外总数 |
| 交付影响 | 承诺达成率变化 | 本期承诺达成率 − 上期承诺达成率 | 百分点 | 不适用，按差值计算 |
| 交付影响 | 调整后缺陷密度 | 范围调整后发现的缺陷数 ÷ 调整后完成的工作量 | 个/故事点或个/工作项 | 调整后完成工作量 |
范围变更率把新增、移出、替换合并计算，反映总体波动；三项分列则能看出波动的结构。新增多、移出少，说明范围在膨胀；新增与移出接近，可能是需求替换而非单纯加码。替换率单独列出，是因为替换往往意味着原计划工作被放弃，对承诺的影响与单纯新增不同。
例外次数是绝对数，适合在迭代回顾中逐条核对；例外原因分类占比用于跨迭代观察哪类原因反复出现。交付影响类指标不直接衡量规则本身，而是衡量规则失效或生效之后的后果，解读时要与波动指标对照，避免把交付波动全部归因于范围调整。
数据口径：分母、计量单位与缺失值处理
指标不可比，多数时候不是公式写错，而是口径不一致。分母的选择是第一道关口。以迭代启动基线为分母，衡量的是“相对原计划变动了多少”，适合评估规则对承诺的保护作用；以期末总量为分母，衡量的是“最终范围里有多少是变动来的”，数值通常更小，且会随迭代推进而变化。两种口径都能用，但同一组趋势分析必须固定一种，并在口径说明中写明。
计量单位建议统一为故事点，或统一为工作项数量。故事点反映工作量，适合评估对交付能力的影响；工作项数量反映条目增减，适合观察需求流动。两者混用时不能直接相加，应分列统计，或事先约定换算规则并保持稳定。若团队部分工作项没有估点，需要明确是按均值估算还是单独归入“未估点”一栏。
缺失值处理直接影响遵守率的真实性。未评估、未记录原因的变更，应单独计入“未记录变更”一栏，保留在分母中，不能因为记录缺失就从统计中剔除，否则会高估遵守率。跨迭代移入移出的工作项，按变更实际发生的时间归属到对应迭代，并在口径中写明移入是否计入新增、移出是否计入移出；同一工作项在多个迭代间反复移动时，按每次移动分别记录。
分母为零的情况要单独约定。例如某迭代没有基线范围，或统计窗口内没有发生任何变更，相关比率指标记为“不适用”，不按零值参与趋势计算，也不参与平均值汇总，避免拉低整体水平造成误判。
计算与评估步骤：从取数到结论
指标计算需要一条固定的流程，保证每次评估都能复现。以下五步可以作为常规做法。
- 锁定迭代基线范围并留存快照。在迭代启动确认范围时，记录纳入的工作项清单、各自的故事点或数量、总基线工作量，以及快照时间。快照是后续所有比率的分母来源，缺失快照的迭代只能做定性评估。
- 逐条记录范围变更。每条变更记录变更类型（新增、移出、替换）、涉及工作项、工作量、发生时间、原因、是否提交申请、评估与审批状态。替换需要同时记录被替换项和替换项，避免只记一半。
- 按公式计算各项指标。先算遵守类，再算波动类，最后算例外与影响类。计算时核对分母是否与快照一致，单位是否统一，未记录变更是否已单列。
- 按迭代与趋势两个层次解读。单迭代看结构，例如新增占比高还是移出占比高，例外集中在哪类原因；多迭代看走向，例如遵守率是否随规则宣贯上升，波动率是否随需求澄清前移而下降。
- 结合例外清单做定性复核。把例外次数对应的具体条目调出来，逐条确认原因分类是否准确，判断是规则条款不适用，还是执行环节缺少提醒。定性复核的结论应回写到规则改进建议中。
记录模板至少包含：迭代名称、基线快照时间与总工作量、变更明细表（工作项、类型、工作量、原因、申请与审批状态、发生时间）、例外清单、各项指标计算结果与口径备注。模板固定后，各迭代按同一结构填写，趋势分析才有基础。
范围变更的类型、原因与审批状态需要留痕，才能支撑上述计算。ONES Project 支持将需求和相关任务规划至迭代并分配负责人，看板和燃尽图用于跟踪进度，报表可自定义数据范围和维度；在迭代回顾阶段，ONES 敏捷研发方案提供燃尽图、工时日志等数据报表，用于复盘进度、质量和成本偏差。团队可以把变更记录、审批状态和基线快照放在工作项与迭代管理中承载，具体字段和流程配置按团队实际设置确定。
例子：一个迭代的范围调整指标计算
以下为演示情景，数字为假设，用于说明公式和解读方式。
某迭代启动时确认基线范围为 100 个故事点，共 20 个工作项。迭代过程中发生如下变动：新增 3 个工作项共 12 点，移出 2 个工作项共 8 点，替换 1 个工作项（原 5 点换成 6 点，按替换工作量 5 点计）。变更申请记录覆盖了新增中的 2 项和移出中的 1 项，替换项未提交申请；提交申请的变更中，有 2 项完成了评估与审批。
| 指标 | 计算过程 | 结果 |
|---|---|---|
| 范围变更率 | （12 + 8 + 5）÷ 100 | 25% |
| 新增工作量占比 | 12 ÷ 100 | 12% |
| 移出工作量占比 | 8 ÷ 100 | 8% |
| 范围替换率 | 5 ÷ 100 | 5% |
| 变更申请率 | 3 ÷ 6 | 50% |
| 评估审批完成率 | 2 ÷ 3 | 66.7% |
从数字看，范围变更率 25%，其中新增占 12 个百分点，是波动的主要来源，说明迭代中后期仍在承接新需求。变更申请率只有 50%，6 项变动中有 3 项没有申请记录，替换项完全未走流程，这是规则执行的主要缺口。评估审批完成率 66.7%，意味着即使提交了申请，也有三分之一没有走完审批，需要确认是审批人响应不及时，还是流程节点设置过多。
例外记录方面，未申请的 3 项变更应逐条登记原因，例如“紧急线上问题插入”“需求方直接与开发沟通”“替换项被当作同等工作量处理”。按原因归类后，若“紧急插入”反复出现，说明规则需要为紧急场景补充快速通道；若“直接沟通”占比高，说明申请入口不够便利或团队对规则认知不足。这些定性信息与比率指标结合，才能定位改进点。
解读与限制：指标能说明什么、不能说明什么
指标反映的是记录下来的行为，记录本身是否完整决定了指标的可靠性。低变更率不一定说明规则执行得好，也可能是变更没有被记录，或者调整被挪到迭代边界之外；高遵守率也不等于范围控制有效，如果审批流于形式、评估结论总是“同意”，遵守率再高也无法保护交付承诺。解读时应先检查记录完整性，再看比率。
指标受迭代长度、团队规模、需求性质影响较大。两周迭代与四周迭代的变更窗口不同，探索型需求与维护型需求的波动基线也不同，跨团队、跨迭代类型直接横向比较意义有限。更合适的做法是在同一团队、相似迭代类型内部看趋势，把外部对比作为参考而非结论。
单指标不宜作为全部判断依据。建议把遵守类、波动类、例外类、影响类组合使用：遵守率回答“流程走没走”，波动率回答“变了多少”，例外分布回答“为什么绕开”，影响指标回答“变了之后怎么样”。四组指标加上例外清单的定性复核，才能形成对规则执行情况的完整判断，并据此决定是修订规则条款、优化审批流程，还是加强记录习惯。
常见问题
迭代中途插入紧急需求，这类变更在指标里怎么算才不冤枉团队？
紧急插入仍然计入范围波动，否则范围变更率会失真。区别在于把它作为单独一类原因登记，在例外原因分类占比中体现出来。这样既保留了“范围确实变了”的事实，也能看出紧急插入占全部变更的比重。如果某类紧急原因反复出现，说明规则需要为它补一条快速通道，而不是让团队长期靠绕流程解决。
团队没有给所有工作项估点，范围变更率还能算吗？
可以算，但要先定好处理方式并保持稳定。常见做法有两种：一是对未估点工作项按同类工作项均值折算，二是不折算，单独统计“未估点变更”的条目数，与按故事点计算的比率并列呈现。两种方式都能用，关键是同一组趋势分析里不混用，并在口径说明中写清楚，否则不同迭代的数值无法比较。
一个迭代里范围几乎没变，是不是说明规则执行得很好？
不一定。范围变更率低可能来自三种情况：规则确实被遵守、变更发生了但没有记录、调整被挪到迭代边界之外处理。判断时需要交叉检查变更申请记录是否完整、例外清单是否有条目、迭代外是否出现了计划外的工作项。把低变更率直接当作执行良好的证据，容易掩盖记录缺失的问题。
这些指标适合用来考核团队吗？
更适合作为规则健康度的诊断工具。一旦与考核挂钩，团队可能通过少报变更、把调整推到迭代外等方式维持好看的数值，反而让数据失去参考价值。如果确实需要与绩效关联，建议以例外原因分布和规则改进建议的落地情况为主，比率指标只作为讨论素材，并配合定性复盘使用。
跨迭代移入移出的工作项，应该算在哪个迭代？
按变更实际发生的时间归属到对应迭代，并在口径中写明移入是否计入新增、移出是否计入移出。同一工作项在多个迭代间反复移动时，每次移动分别记录，避免只记最终结果。这样处理能让每个迭代的波动指标反映当期真实发生的调整，也便于追溯某次移动的决策背景。
