统计迭代范围调整的例外情况，核心是口径先行：先明确什么算范围调整、什么算例外，再以单个迭代为统计单元逐条打标，最后计算例外率并分组汇总。本文给出指标定义、取数规则、计算公式和一个完整算例，帮助你把例外数量转化为可复核的规则执行证据。
要点总览（TL;DR）
- 先定义口径再统计：范围调整指迭代开始后新增、删除、替换需求或改变优先级并影响本迭代工作量；例外指未按规则流程完成的调整，如未评审、超时限补审批、超阈值未升级。
- 以单个迭代为统计单元，核心公式为例外率＝例外调整条数÷范围内全部调整条数×100%；分母为零时记为不适用，不按0%参与平均。
- 取数依赖范围变更记录、评审记录和需求状态变更历史，按需求编号关联；无评审记录按未走流程标记，时间缺失的记录不参与平均处理时长。
- 解读时至少合并三到五个迭代看趋势，用总条数之比而非比率平均；紧急修复迭代与常规迭代分开比较，例外率不直接作为绩效结论。
- 迭代结束时未完成的需求重新评估后决定是否纳入下一迭代，属于正常计划动作，不计入范围调整例外。
评估目标：例外统计要回答什么问题
例外统计通常服务于两类目的，需要分开设定，否则容易把盘点结果误读成考核结论。第一类是规则执行效果评估：范围调整规则在实际迭代中是否被遵守，哪些环节最容易被绕过。第二类是例外情况盘点：某段时间内发生了多少例外、集中在哪些需求类型和责任人身上，用于估算沟通与返工成本。
两类目的对应不同的决策场景。规则执行效果评估的结果用于修订规则本身，例如某类调整的审批时限设置过紧导致大量超时，就应考虑调整时限而非追责；例外情况盘点的结果用于流程改进，例如发现未评审的调整集中在迭代后期，可以增加中期范围确认节点。下表列出目的与决策场景的对应关系。
| 评估目的 | 典型问题 | 对应决策场景 |
|---|---|---|
| 规则执行效果评估 | 规则流程的遵守比例是多少，哪条规则最常被绕过 | 修订审批时限、阈值或评审要求 |
| 例外情况盘点 | 例外集中在哪些环节、类型和责任人 | 增加范围确认节点、调整沟通机制 |
| 沟通成本评估 | 例外调整平均多消耗多少审批与协调时间 | 评估规则简化或自动化的收益 |
需要强调的是，例外多不等于规则失效。例外可能来自规则设计与业务节奏不匹配，也可能来自紧急情况的合理变通。统计时应结合调整原因逐条判断，把“规则不合理导致的例外”和“执行不到位导致的例外”区分开，再决定改规则还是改执行。
指标与范围：统计哪些调整、哪些算例外
统计对象是迭代开始后发生的范围调整。判定标准是：在迭代进行期间新增、删除、替换需求，或改变需求优先级并导致本迭代工作量发生变化。迭代开始前完成的需求池调整不计入；仅修改描述、补充验收标准等不影响工作量的编辑也不计入。
例外指未按既定规则流程完成的调整。常见情形包括：未经评审直接纳入迭代、超过规定时限才补审批、单次调整量超过阈值未走升级流程、审批人不在授权名单内。规则的具体条款因团队而异，统计前应把本团队的范围调整规则逐条转成可判定的条件，避免打标时凭印象。
统计单元为单个迭代，时间窗取迭代起止日期。跨迭代的调整按申请时间归属到对应迭代；同一需求在一个迭代内多次调整，按调整事件计数而非按需求计数，去重规则在下一节说明。指标清单如下表。
| 指标名称 | 口径 | 单位 | 分母 |
|---|---|---|---|
| 调整总条数 | 迭代期间发生的范围调整事件数（去重后） | 条 | 无 |
| 例外条数 | 打标为例外的调整事件数 | 条 | 无 |
| 例外率 | 例外条数÷调整总条数 | % | 调整总条数 |
| 类型分布 | 各例外类型条数及占例外总数比例 | 条、% | 例外条数 |
| 平均处理时长 | 例外调整从申请到审批完成的平均时长 | 小时或天 | 有完整时间记录的例外条数 |
平均处理时长的分母只包含申请时间和审批时间都完整的记录，缺失时间的记录单独列出，不参与均值计算，避免用估算值拉偏结果。
数据口径与证据：从哪些记录取数
例外统计依赖三类记录：迭代范围变更记录、评审记录、需求状态变更历史。范围变更记录提供调整事件本身，评审记录提供是否走流程的证据，状态变更历史用于补全时间线和识别未登记的调整。三类记录通过需求编号关联，形成一条可追溯的证据链。
关键字段包括：需求编号、调整类型（新增、删除、替换、优先级变更）、申请时间、审批时间、审批人、调整原因、所属迭代。调整原因建议使用受控选项而非自由文本，便于后续按原因分组，例如“客户紧急插入”“原需求估算偏差”“依赖方延期”“规则豁免”。
缺失值和口径冲突需要预先定规则，否则不同人算出的结果无法对齐。常见处理方式如下：
- 有调整记录但无对应评审记录：按“未走流程”标记为例外，并在备注中注明记录缺失，便于复核。
- 审批时间缺失但审批人存在：标记为“流程不完整”，计入例外，处理时长不参与均值。
- 同一需求在同一迭代内多次调整：按调整事件分别计数；若为同一天内的重复登记，合并为一条并保留最早申请时间。
- 调整记录与状态变更历史冲突：以范围变更记录为准，冲突项列入待核对清单，核对后再纳入统计。
证据留存要求是每条统计结果都能回溯到具体需求和迭代。原始记录导出后应保留快照，统计表增加需求编号列，确保任何人按同样口径可以复算出相同数字。在工具层面，ONES 的工作项状态历史和迭代范围变更记录可以作为这类取数的承载：需求在迭代内的状态流转、字段修改会留下操作记录，评审与审批动作可以关联到对应工作项，统计时按迭代和时间窗导出即可，减少手工补录带来的口径偏差。
计算步骤：从原始记录到例外率
计算流程分五步，每步都有明确的完成标志，便于交接和复核。
- 导出调整记录：按迭代起止日期导出范围变更记录、评审记录和状态变更历史，保存原始文件快照。
- 去重与合并：按需求编号和调整时间识别重复登记，合并同一天内的重复条目，形成调整事件清单。
- 逐条打标：对照规则条款为每条调整标注“合规”或例外类型，例外类型使用受控选项，打标人和打标时间一并记录。
- 按迭代汇总：统计调整总条数、例外条数，按类型、发生环节、责任人分组计数。
- 计算比率：计算例外率及分组占比，处理分母为零的情况。
核心公式为：例外率＝例外调整条数÷范围内全部调整条数×100%。分母为零表示该迭代没有发生范围调整，此时例外率标记为“不适用”，不记为0%，也不参与多迭代平均值的计算。多迭代合并观察时，用各迭代例外条数之和除以调整条数之和，而非对各迭代例外率取简单平均，避免小样本迭代的比率被过度加权。
交叉统计按三个维度展开：按例外类型分组，看哪类规则最常被绕过；按发生环节分组，区分迭代前期、中期、后期，判断是否集中在交付压力大的阶段；按责任人分组，用于识别沟通和培训需求，分组结果只作为改进线索，不直接用于绩效评价。分组时样本量过小的组应合并或标注样本数，避免用一两条记录下结论。
例子：一个迭代的例外统计演示
以下为演示情景，数据为虚构，用于说明计算过程。某迭代周期为两周，期间共发生 10 条范围调整事件，逐条打标结果如下表。
| 需求编号 | 调整类型 | 发生阶段 | 打标结果 | 例外类型 |
|---|---|---|---|---|
| R-101 | 新增 | 前期 | 合规 | — |
| R-102 | 优先级变更 | 前期 | 合规 | — |
| R-103 | 新增 | 中期 | 例外 | 未评审 |
| R-104 | 替换 | 中期 | 合规 | — |
| R-105 | 新增 | 后期 | 例外 | 超时限补审批 |
| R-106 | 删除 | 后期 | 例外 | 未评审 |
| R-107 | 优先级变更 | 中期 | 合规 | — |
| R-108 | 新增 | 后期 | 例外 | 超阈值未升级 |
| R-109 | 替换 | 前期 | 合规 | — |
| R-110 | 删除 | 后期 | 合规 | — |
计算过程：调整总条数 10 条，例外条数 4 条，例外率＝4÷10×100%＝40%。按例外类型分布：未评审 2 条（占例外 50%），超时限补审批 1 条（25%），超阈值未升级 1 条（25%）。按发生阶段分布：前期 0 条，中期 1 条，后期 3 条，后期例外占全部例外的 75%。
从示例可以读出两个薄弱环节：一是未评审是最大例外类型，说明评审环节的触发机制可能不够明确；二是例外集中在迭代后期，与交付压力下的临时插入相符。对应的改进动作可以是明确后期调整必须走快速评审通道，以及为超阈值调整设置更清晰的升级入口。若该迭代调整总条数为零，则例外率记为不适用，上述分组统计也不产生有效结论。
解读与限制：例外率能说明什么、不能说明什么
例外率反映的是规则执行的一致性，即范围调整在多大比例上按既定流程完成。它不直接反映团队交付能力，也不能单独作为绩效结论。一个例外率高的迭代，可能交付结果良好，只是流程被频繁变通；一个例外率低的迭代，也可能因为调整本身就少而缺乏代表性。
样本量是解读时的首要限制。单个迭代的调整条数通常只有几条到十几条，一两条记录的增减就会让例外率大幅波动。建议至少合并三到五个迭代观察趋势，合并时使用总条数之比而非比率平均。样本量过小的分组，例如某责任人只有一条例外记录，应标注样本数，不作为个人评价依据。
不同迭代类型之间不宜直接横向比较。紧急修复类迭代的调整频率和例外比例天然高于常规迭代，把两者放在同一张对比表里会得出误导性结论。比较时应限定相同类型的迭代，或分别列出基线。
未完成工作的处理需要单独说明：迭代结束时未完成的需求应重新评估后决定是否纳入下一迭代，重新评估属于正常的计划动作，不计入范围调整例外。只有绕过规则流程的调整才计入例外，这一区分能避免把计划调整误算成流程问题。
常见误用清单如下：把例外率当作团队排名依据；用单迭代比率下结论；忽略分母为零的迭代直接按0%参与平均；把紧急修复迭代与常规迭代混算；只统计例外条数而不看类型和阶段分布。避开这些误用，例外统计才能稳定地服务于规则修订和流程改进。
常见问题
迭代内同一需求被多次调整，统计时按需求还是按调整事件计数？
按调整事件计数，即同一需求在同一迭代内每发生一次范围调整就记一条，这样例外率反映的是流程被绕过的频次。同一天内对同一需求的重复登记属于记录重复，应合并为一条并保留最早申请时间。若两次调整间隔多日、原因不同，则分别计数并各自打标。
团队还没有成文的范围调整规则，能先做例外统计吗？
可以先做盘点，但结论要限定为“调整情况盘点”而非“例外率”。没有成文规则时，先按常见流程要求（是否评审、是否有时限、是否设阈值）临时约定判定条件并写下来，统计结果用于推动规则成文。规则定稿后，新旧口径不同，前后数据不宜直接比较。
某个迭代没有发生范围调整，例外率应该填0%还是空着？
记为“不适用”，不填0%。分母为零时比率没有定义，填0%会让该迭代在多迭代平均中被当作执行良好而拉低整体水平。合并观察时，这类迭代只贡献零条调整，不参与比率平均，用各迭代例外条数之和除以调整条数之和即可。
例外统计结果能不能直接用于团队或个人考核？
不建议直接使用。单个迭代的调整条数往往只有几条到十几条，一两条记录就能让例外率大幅波动；按责任人分组后样本更小，容易把偶发情况读成个人问题。更稳妥的用法是把例外类型和发生阶段的分布作为规则修订与流程改进的线索，考核另设与交付结果相关的指标。
紧急插入的需求走了口头同意但没补审批，算不算例外？
算例外。判定依据是是否按规则流程留下审批记录，口头同意不构成流程证据。这类情况建议在打标时单独标注“紧急变通”，与“未评审直接纳入”区分开，便于后续判断是规则时限过紧还是执行习惯问题。若团队希望紧急通道合法化，应把快速审批条件写进规则，而不是在统计时放宽口径。
