迭代目标达成率按“已达成目标项数÷迭代承诺目标项数×100%”计算，难点在于分子分母的边界和“达成”的判定标准。本文给出可直接套用的公式、目标项纳入排除规则、完成定义与证据要求、判定分级方法，并用一个完整示例演示计算过程，最后说明结果解读时的限制和未完成目标的处理方式。
要点总览（TL;DR）
- 迭代目标达成率 = 达成目标项数 ÷ 承诺目标项数 × 100%，分母只统计迭代计划会上确认的承诺目标项，分子只统计结束时间点满足完成定义的目标项。
- 判定口径要在迭代开始前固定：目标清单与编号、每项完成定义与证据类型、统一取数时点、部分完成与未确认的处理规则、分级阈值、分母为零的处理方式。
- 部分完成的目标项单列记录完成度说明，不计入分子；中途新增且未纳入承诺的目标和被正式取消的目标不进入分母；数据缺失标记为未确认，同样不计入分子。
- 分母为零时该迭代不计算达成率，标注为无承诺目标；口径变更需留痕，从下一迭代起适用，不追溯修改已归档迭代。
- 达成率受目标难度和拆分粒度影响，不可直接横向比较，需结合目标项明细和定性复盘解读；未完成工作重新评估后纳入后续迭代，不默认自动结转。
评估目标：达成率要回答什么问题
迭代目标达成率回答一个具体问题：团队在迭代开始时承诺要完成的目标，到迭代结束时间点兑现了多少。它衡量的是承诺的兑现程度，统计单位是目标项，不是任务、故事点或工时。这个定位决定了它的使用场景——迭代复盘时判断计划与执行的偏差，以及观察多个迭代之间承诺兑现的稳定性。
达成率与常见的其他迭代指标回答不同的问题，不能互相替代：
| 指标 | 统计对象 | 回答的问题 |
|---|---|---|
| 迭代目标达成率 | 迭代承诺的目标项 | 承诺的目标是否按期兑现 |
| 故事点完成率 | 已估算的工作量 | 计划工作量完成了多少 |
| 需求交付数量 | 交付的需求条目 | 这个迭代产出了多少需求 |
三者的差异在于统计单位和判断对象。故事点完成率关注工作量消耗，需求交付数量关注产出规模，达成率关注目标层面的承诺兑现。一个迭代可能交付了大量需求，但承诺的关键目标没有完成，此时达成率低而交付数量高，两个结果都真实，只是说明的问题不同。
使用边界需要在度量设计时就写清楚：达成率用于团队复盘和迭代改进，作为讨论计划合理性、目标拆分质量、风险识别时机的输入。它不适合直接换算为个人绩效，因为目标项通常由多人协作完成，单个目标项的未达成往往涉及需求澄清、依赖协调、技术风险等多重因素，归因到个人会失真。把这条边界写进度量说明，可以避免指标被误用后失去团队的信任。
指标与范围：分子分母各统计什么
达成率的计算公式为：
迭代目标达成率 = 达成目标项数 ÷ 承诺目标项数 × 100%，单位为百分比，保留一位小数即可，同时保留分子分母的原始整数，便于复核。
分母是迭代开始时确认的承诺目标项。操作上要求：在迭代计划会上逐项列出本迭代要完成的目标，为目标项编号，记录确认时间和参与确认的角色。分母一旦在计划会结束时固定，迭代过程中不再因新增工作而扩大。目标项应当是可判断完成与否的条目，例如“完成订单导出功能并通过验收”“支付接口响应时间降至约定阈值以内”，而不是“优化系统性能”这类无法核验的表述。
分子是在迭代结束时间点满足完成定义的目标项。判断依据是完成定义和证据，不是任务状态标签。一个目标项下的所有任务都标记为完成，但验收尚未通过，仍不计入分子。
纳入排除规则需要逐条明确：
- 计入分母：迭代计划会上确认的承诺目标项，含编号与确认时间。
- 不计入分母：迭代中途新增且未纳入承诺的目标。这类工作可以单独记录为“迭代内插入工作”，用于分析计划被打断的程度，但不改变本期达成率的分母。
- 不计入分母：被正式取消的目标项，需记录取消时间、决策人和原因。取消不等于达成，也不应悄悄从分母中消失而不留痕迹。
- 部分完成的目标项：单列记录，注明完成到哪一步，不计入分子。部分完成的信息在复盘中比一个百分比更有价值，不要为了凑数把它折算成小数计入分子。
这套规则的核心是让不同迭代、不同团队按同一口径统计。如果某个团队习惯把中途插入的需求也算进分母，另一个团队不算，两边的达成率就没有可比性。规则本身可以讨论调整，但要在统计周期开始前定好，并在多个迭代中保持一致。
数据口径与证据：完成定义和取数来源怎么定
“达成”必须有可核验的证据支撑，否则达成率会退化为主观判断的汇总。做法是在迭代开始时为每项目标写明完成定义，并约定对应的证据类型。
完成定义要写到可以判断“是或否”的程度。常见写法包括：功能已上线并可被目标用户访问；需求通过验收，验收记录中有验收人签字或系统确认；某项指标在约定统计周期内达到预设阈值；评审会形成通过结论并记录。模糊表述如“基本完成”“主要功能可用”不能作为完成定义。
证据类型与完成定义对应，常用的有验收记录、上线记录、评审结论、指标数据截图或报表导出。每项目标在计划阶段就应指明用哪类证据判断，避免结束时临时找依据。
取数时点统一为迭代结束日的固定时点。跨时区团队要约定一个基准时间，例如以团队主要办公时区的当日 18:00 为准，所有目标项按同一时点核对状态。结束时间点之后才满足完成定义的目标，计入下一个统计周期，不追溯修改本期结果。
数据缺失的处理规则要提前写定：无法取得证据或证据不足以判断的目标项，标记为“未确认”，不计入分子，并在复盘中说明缺失原因。未确认与未达成在记录上分开，前者是数据问题，后者是执行结果，混在一起会掩盖流程缺陷。
口径变更需要留痕。如果团队决定调整完成定义或纳入规则，记录变更时间、变更内容和原因，从下一个迭代开始适用，已归档迭代的结果保持不变。追溯修改历史数据会让趋势分析失去意义。
下面是一张可直接填写的目标项完成定义与证据对照表的结构：
| 目标项编号 | 目标描述 | 完成定义 | 证据类型 | 核对结果 | 备注 |
|---|---|---|---|---|---|
| G-01 | 订单导出功能上线 | 功能上线且目标用户可访问 | 上线记录 | 达成 | — |
| G-02 | 支付接口性能达标 | 约定统计周期内响应时间达到阈值 | 监控报表 | 部分完成 | 峰值时段未达标 |
在工具层面，目标清单和完成状态的记录方式直接影响这套口径能否落地。ONES 的迭代规划环节支持产品负责人按优先级把待办需求规划到迭代，并在迭代计划会上与团队就本期要完成的需求和验收标准达成一致；迭代过程中团队通过看板管理任务状态，迭代结束后可结合燃尽图、工时日志等报表复盘进度偏差。把承诺目标项作为迭代内的固定清单维护，把完成定义和验收结论记录在对应需求上，结束时的核对就有据可查。需要说明的是，达成率的具体指标和报表模板是否现成提供，属于选型时需要向厂商确认的事项。
计算与判定步骤：从目标清单到结论
按以下五步操作，不同人执行应得到相同结果。
第一步，整理承诺目标清单。从迭代计划会记录中提取本期承诺目标项，逐项编号，补齐每项的完成定义和证据类型。清单确认后锁定，作为分母的原始依据。
第二步，在结束时间点逐项核对证据。按统一基准时间，对每项目标检查证据是否满足完成定义，标记为“达成”“未达成”或“未确认”。核对人和核对时间一并记录。
第三步，代入公式计算。达成目标项数除以承诺目标项数乘以100%，同时保留分子分母原始数字。例如分子4、分母6，达成率约66.7%。
第四步，按预设分级判定。分级阈值在迭代开始前确定，全团队使用同一套。一个可用的分级示例如下：
| 分级 | 达成率区间 | 含义 |
|---|---|---|
| 全部达成 | 100% | 承诺目标全部兑现 |
| 多数达成 | 80%–99% | 大部分目标兑现，少量偏差 |
| 部分达成 | 50%–79% | 约半数目标兑现，计划或执行存在明显偏差 |
| 未达成 | 低于50% | 多数承诺目标未兑现，需重点复盘 |
阈值本身没有通用标准，团队可根据自身历史数据和改进目标设定，关键是提前固定、长期一致，避免每次算完再挑一个合适的区间解释结果。
第五步，记录未达成项的原因与后续安排。对每个未达成和未确认的目标项，写明偏差原因（需求变更、依赖阻塞、估算偏差、证据缺失等）和后续处理建议。未完成的工作重新评估优先级和范围后，决定是否纳入后续迭代，不默认自动结转。
分母为零时，该迭代不计算达成率，标注为“无承诺目标”，并在复盘中说明为何没有承诺目标。这种情况本身就是一个值得讨论的信号，不要用0%或100%代替。
例子：一个迭代的达成率计算演示
以下为演示情景，用于说明计算过程。某团队在迭代计划会上确认6项承诺目标，迭代结束日按统一基准时间核对，结果如下：
| 编号 | 目标项 | 完成定义 | 证据核对 | 结果 |
|---|---|---|---|---|
| G-01 | 订单导出功能上线 | 上线且目标用户可访问 | 上线记录完整 | 达成 |
| G-02 | 支付接口性能达标 | 统计周期内响应时间达阈值 | 监控报表显示峰值未达标 | 未达成 |
| G-03 | 用户权限改造通过验收 | 验收记录确认通过 | 验收记录齐全 | 达成 |
| G-04 | 报表页面改版上线 | 上线且评审通过 | 上线记录与评审结论齐全 | 达成 |
| G-05 | 消息通知模块联调完成 | 联调通过并记录结论 | 主流程通过，异常分支未覆盖 | 部分完成 |
| G-06 | 数据迁移脚本验证 | 验证报告确认通过 | 验证报告未归档，无法确认 | 未确认 |
统计结果：达成4项，部分完成1项，未达成1项，未确认1项。分母为承诺的6项，分子为达成的4项，达成率 = 4 ÷ 6 × 100% ≈ 66.7%。
按预设分级，66.7% 落在50%–79%区间，判定为“部分达成”。部分完成的 G-05 不计入分子，其完成度说明保留在记录中；未确认的 G-06 同样不计入分子，需在复盘中说明验证报告缺失的原因，并检查归档流程是否存在漏洞。
未达成项的处理：G-02 记录为性能优化未达预期，原因指向峰值流量下的缓存策略不足，后续安排专项优化并重新设定验证口径；G-05 的异常分支覆盖作为剩余工作重新评估后纳入下一迭代；G-06 补齐验证报告后，在下一迭代重新确认。三项都不自动结转，而是经过优先级评估后重新进入计划。
解读与限制：达成率不能说明什么
达成率是一个有用的复盘输入，但它能说明的范围有限，解读时需要主动加上限定。
目标难度不同，达成率不可直接横向比较。一个迭代的目标是上线一个成熟模块的小改动，另一个迭代的目标是攻克一项未验证的技术方案，两者都承诺5项、都达成4项，背后的难度和风险完全不同。跨团队比较达成率时，这个差异会被放大，容易得出误导性结论。比较应限定在目标性质相近的迭代之间，或者只做自身纵向趋势观察。
目标项粒度差异会显著影响结果。把一个大目标拆成五项小目标，达成率的分母变大，单项未完成对百分比的影响变小；反之，目标合并会让单个失败拉低整体数值。团队需要固定目标拆分规则，例如按可独立验收的交付物拆分，并在多个迭代中保持一致，否则趋势数据会因拆分习惯变化而失真。
达成率高不等于产出价值高。如果承诺的目标本身定得保守，或者目标内容与业务价值关联弱，100%的达成率只说明承诺兑现得好，不说明这个迭代做对了事。解读达成率时必须同时看目标项明细：完成了哪些目标、这些目标解决了什么问题、有没有该做而未纳入承诺的重要工作。
未完成工作的处理要写进规则：重新评估后纳入后续迭代，不默认自动结转。自动结转会让分母不断膨胀，也会让团队对承诺失去敬畏，本期未完成的工作悄悄变成下期的负担，达成率反而失去诊断价值。
最后，达成率应与定性复盘结合使用。数字指出偏差发生在哪里，复盘讨论解释为什么发生、下次怎么调整。把单一百分比当作绩效考核依据，会诱导团队在目标设定上做文章——把目标写小、写模糊、写容易达成的条目，指标就失去了改进作用。度量体系的设计者需要在规则层面就防住这种倾向，例如保留目标项明细供评审、定期检查目标难度分布。
常见问题
迭代中途插入的紧急需求，要不要算进达成率的分母？
不计入本期分母。分母在迭代计划会结束时固定，中途新增且未纳入承诺的工作单独记录为“迭代内插入工作”，用于分析计划被打断的程度。这样处理能让不同迭代的达成率保持同一口径。如果团队希望反映插入工作的影响，可以在复盘时把插入工作量与承诺目标项数并列呈现，而不是临时扩大分母。
目标项下的任务全部完成，但验收还没通过，算达成吗？
不算。分子只统计在迭代结束时间点满足完成定义的目标项，判断依据是完成定义和证据，任务状态标签不作为依据。验收未通过的目标项按未达成记录；如果验收结论在结束时间点之后才形成，计入下一个统计周期，不追溯修改本期结果。
团队第一次做这套度量，分级阈值怎么定比较合适？
可以先按历史迭代的实际数据回算几期，观察达成率的分布，再确定分级区间，避免阈值定得过高或过低而失去区分度。阈值一旦确定，在多个迭代中保持一致，至少积累三到五期数据后再评估是否调整。调整时记录变更时间和原因，从下一迭代起适用。
达成率偏低时，复盘应该先查什么？
先看未达成和未确认目标项的明细，区分三类原因：目标设定问题（目标过大、完成定义模糊）、执行问题（依赖阻塞、估算偏差）、数据问题（证据缺失、归档不及时）。三类原因的改进动作不同，混在一起讨论容易停留在“下次努力”的层面。同时核对分母是否包含了大颗粒目标，粒度差异会放大单项失败对百分比的影响。
用工具记录目标清单和完成证据时要注意什么？
关键是让承诺目标项成为迭代内可追溯的固定清单，并把完成定义和验收结论记录在对应需求上。以 ONES 为例，迭代规划环节支持产品负责人按优先级把需求规划到迭代，并在计划会上与团队就本期要完成的需求和验收标准达成一致；迭代中通过看板管理任务状态，结束后可结合燃尽图、工时日志等报表复盘偏差。达成率指标和报表模板是否现成提供，属于选型时需要向厂商确认的事项。
