迭代中新增或取消需求，会直接改变计划达成率的分子与分母，使同一指标在不同时点算出不同结果。要回答“计划是否可靠”，需要先固定统计基准：以迭代启动时承诺的需求集合为分母，以其中按期完成的需求数为分子，新增与取消需求单列为范围变更，并同时报告原始达成率与含变更达成率。
要点总览（TL;DR）
- 新增需求会扩大分母、取消需求会改变承诺集合，两者都会让计划达成率在不同时点算出不同结果，因此统计前要先固定基准。
- 以迭代启动时承诺的需求集合为分母、其中按期完成的需求数为分子，计算原始计划达成率，衡量承诺兑现程度。
- 同时报告含变更达成率（分母加入新增需求）和范围变更率（新增与取消需求占承诺需求的比例），把承诺兑现与范围稳定性分开解释。
- 取消需求不宜直接从分母扣除，否则会抬高达成率、掩盖承诺失效；跨迭代顺延的需求在原迭代计为未完成，在新迭代重新计入。
- 达成率波动需结合估算偏差、范围变更和外部依赖分类解读，不设通用达标线，按团队历史基线比较，不直接等同个人绩效。
评估目标：要回答计划可靠性还是范围稳定性
计划达成率回答的是承诺兑现程度：迭代开始时团队承诺交付的需求，最终有多少按期完成。它衡量的是“说到做到”的能力，适合用来观察估算准确性、排期合理性和交付节奏的稳定性。
新增与取消需求属于范围变更，是另一类问题。新增需求意味着迭代目标扩大，取消需求意味着原承诺失效，两者都会让实际范围偏离启动时的约定。范围变更本身不一定是坏事，但它需要被单独记录和度量，否则会被混入达成率，让指标失去解释力。
两类指标组合使用，才能解释达成率波动的来源。例如达成率下降，若范围变更率同时上升，说明主要压力来自范围波动；若范围变更率平稳而达成率下降，则更可能指向估算偏差或执行受阻。评估目标应明确写成两句话：计划达成率看承诺兑现，范围变更率看范围稳定性，二者不互相替代。
指标与范围：达成率、范围变更率与统计边界
建议同时定义三个指标，并统一统计边界，避免每次取数时重新争论口径。
| 指标 | 定义 | 统计对象 | 时间窗 |
|---|---|---|---|
| 原始计划达成率 | 按期完成的承诺需求数 ÷ 迭代启动时承诺需求数 × 100% | 迭代启动时已纳入承诺集合的需求 | 迭代起止日期 |
| 含变更达成率 | 按期完成需求数 ÷（承诺需求数 + 新增需求数）× 100% | 承诺需求与迭代内新增需求 | 迭代起止日期 |
| 范围变更率 | （新增需求数 + 取消需求数）÷ 承诺需求数 × 100% | 迭代内发生的新增与取消 | 迭代起止日期 |
统计对象以迭代启动时承诺的需求集合为基准，这个集合需要在启动会上确认并留痕。迭代外插入的紧急事项不计入承诺集合，也不进入上述三个指标，可另设紧急插入率单独观察。需求拆分或合并产生的记录，按拆分合并前的原始需求计数，避免一个需求被重复统计或凭空增加。
时间窗以迭代起止日期为准，完成时间取需求状态流转到“已完成”的时间戳。跨迭代顺延的需求，在原迭代中计为未按期完成，在新迭代中按新承诺重新计入，两个迭代各自独立核算。
数据口径：需求状态、变更记录与分母处理
可复算的前提是取数来源稳定。需求状态流转记录提供完成时间，变更记录提供新增与取消的识别依据，两者都需要保留时间戳和操作人。
- 完成判定：以需求状态流转到约定完成状态的时间戳为准，同一需求多次流转取首次到达完成状态的时间。
- 新增识别：以需求创建时间晚于迭代启动时间、且被纳入该迭代的字段为准，登记时点取纳入迭代的操作时间，而非需求创建时间。
- 取消判定：以需求被移出迭代或标记为取消的状态变更为准，需由需求负责人确认取消原因，区分“业务不需要”与“顺延到后续迭代”。
- 分母为零：迭代启动时承诺需求数为零时，达成率不计算，标记为“无承诺”，不按0%或100%处理。
- 拆分合并：拆分后的子需求合并计为一个原始需求，合并后的需求按合并前各需求分别计数，保证分母与启动时承诺一致。
- 缺失值：缺少完成时间戳的需求计为未完成；缺少变更记录的新增需求，按纳入迭代时间补录，无法补录的单独列出待核对清单。
这些规则应写入度量说明文档，并在每次统计前核对。当需求状态与变更记录在研发管理系统中日常流转时，取数可以依托系统记录完成。ONES Performance 自动收录 ONES 系统内日常流转的研发数据，基于这些数据形成分析指标，并提供多维度、精细化、自定义的分析能力，适合承载需求状态与变更记录的取数基础；具体指标配置方式以实际产品版本为准。
计算步骤：原始达成率、含变更达成率与范围变更率
按以下步骤逐迭代计算，再按需汇总，保证每个数字都能回溯到需求清单。
- 导出迭代启动时承诺的需求清单，记为集合 A，数量为 |A|。
- 从集合 A 中筛出在迭代结束前完成的需求，数量记为 C。
- 统计迭代内新增并纳入该迭代的需求数，记为 N；统计迭代内取消的需求数，记为 X。
- 计算原始计划达成率 = C ÷ |A| × 100%。
- 计算含变更达成率 = C ÷（|A| + N）× 100%。
- 计算范围变更率 =（N + X）÷ |A| × 100%。
按季度汇总时，采用需求数加权，而非对各迭代达成率取简单平均。季度原始达成率 = 各迭代 C 之和 ÷ 各迭代 |A| 之和 × 100%；季度含变更达成率 = 各迭代 C 之和 ÷ 各迭代（|A| + N）之和 × 100%。这样可以避免小迭代与大迭代被同等对待造成失真。
例子：一个迭代的新增与取消如何改变达成率
假设某迭代启动时承诺 20 个需求，迭代结束时其中 16 个按期完成，迭代内新增 4 个需求，取消 2 个需求。以下为演示情景，数值仅用于说明口径差异。
| 口径 | 计算过程 | 结果 |
|---|---|---|
| 原始计划达成率 | 16 ÷ 20 × 100% | 80% |
| 含变更达成率 | 16 ÷（20 + 4）× 100% | 约 66.7% |
| 范围变更率 | （4 + 2）÷ 20 × 100% | 30% |
同一迭代，原始达成率 80%，含变更达成率约 66.7%，差距来自新增的 4 个需求扩大了分母。取消的 2 个需求不进入原始达成率的分子，也不减少分母，而是通过范围变更率体现为承诺失效。若把取消需求直接从分母扣除，原始达成率会变成 16 ÷ 18，结果被抬高，承诺失效的事实被掩盖。
解读时应把两个数字分开看：原始达成率 80% 说明承诺兑现程度尚可，含变更达成率约 66.7% 说明叠加新增后交付压力明显上升，范围变更率 30% 提示该迭代范围波动较大。三者结合，才能判断问题出在承诺兑现还是范围控制。
解读与限制：达成率波动的原因归属与使用边界
达成率下降可能来自三类原因：估算偏差导致承诺量超出实际产能，范围变更导致分母或工作量变化，外部依赖阻塞导致需求无法按期完成。仅看达成率一个数字无法区分这三类原因，需要结合变更原因分类和阻塞记录一起分析。
新增与取消需求的影响应结合原因分类解读。新增若来自紧急业务变化，反映的是需求侧波动；新增若来自前期需求拆分不充分，反映的是需求澄清质量问题。取消若来自业务优先级调整，属于正常范围管理；取消若来自需求本身不成立，则提示前期评审需要加强。原因分类应在变更登记时同步记录，事后补记容易失真。
不设通用达标线。不同团队、不同迭代类型的承诺难度差异很大，用统一百分比判断好坏缺乏依据。更稳妥的做法是与团队自身历史基线比较，观察趋势和波动幅度，再结合范围变更率判断改善方向。
指标用于改进讨论，不直接等同个人绩效。计划达成率受需求来源、依赖方和排期策略影响，把单指标与个人考核挂钩，容易诱发少承诺、拆小需求等规避行为，反而削弱预测价值。将原始达成率、含变更达成率与范围变更率放在同一张仪表盘中持续观察，配合迭代回顾讨论原因，才能让度量服务于计划可靠性的提升。
常见问题
迭代中途取消的需求，能不能从分母里扣掉再算达成率？
不建议直接扣除。取消需求意味着原承诺失效，如果把它从分母移除，原始达成率会被抬高，承诺未兑现的事实被掩盖。更稳妥的做法是保留原分母，把取消需求计入范围变更率，单独观察承诺失效的规模。若团队希望看“剔除取消后的兑现情况”，可以另设一个辅助口径并明确标注，但不应替代原始达成率作为主指标。
新增需求在迭代内完成了，应该计入分子吗？
取决于用哪个口径。原始计划达成率的分子只统计启动时承诺集合中按期完成的需求，迭代内新增并完成的需求不计入，否则分子分母口径不一致。含变更达成率的分母加入了新增需求，此时新增且完成的需求可以计入分子，但需要在度量说明中写清楚，保证同一口径下分子分母的统计对象一致。两个口径同时报告，读者才能看清新增需求带来的实际影响。
需求拆分或合并后，分母怎么处理才不会算错？
按拆分合并前的原始需求计数。一个承诺需求拆成三个子需求，分母仍记为一个；两个需求合并成一个，分母记为两个。这样分母与迭代启动时确认的承诺集合保持一致，避免拆分导致分母虚增、合并导致分母缩水。拆分合并的操作记录应保留在变更日志中，便于复核时还原原始需求与子需求的对应关系。
团队历史数据不足，怎么判断达成率波动是否正常？
先积累至少若干个完整迭代的同口径数据，再观察趋势和波动幅度，而不是套用统一百分比。数据不足时，可以把原始达成率、含变更达成率与范围变更率放在一起看：范围变更率突然上升，往往能解释同期达成率下降。同时结合迭代回顾中记录的阻塞事项和变更原因，判断波动来自估算、范围还是外部依赖。随着迭代增多，逐步形成团队自身的基线区间。
计划达成率能不能直接用于个人绩效考核？
不建议直接挂钩。达成率受需求来源、依赖方排期和范围变更影响，个人可控程度有限。把它与个人考核绑定，容易诱发少承诺、拆小需求、推迟登记变更等规避行为，反而削弱指标的预测价值。更合适的用法是作为团队级改进讨论的输入，配合变更原因分类和迭代回顾，定位承诺兑现或范围控制中的具体问题，再落到可执行的改进动作上。
