迭代排满却交付不足，往往说明计划容量与实际可投入的交付能力存在差距。排查时先量化偏差，再依次核对人员可用性、估算口径、范围变动和执行损耗，用一到两个迭代的数据确认主因，然后调整估算规则并验证效果。
要点总览（TL;DR）
- 迭代排满却交付不足，先算完成率和偏差率，用两到三个迭代的数据确认是系统性偏高还是个别波动。
- 常见主因集中在四类：按名义人力算容量、故事点与工时混用、迭代中范围变动未预留、返工与阻塞损耗未计入。
- 排查按“人员可用性—估算口径—范围变动—执行损耗”逐层验证，每层用数据确认或排除，避免同时改多个变量。
- 处置从核对历史速率开始，重算可承诺容量、统一估算单位、设定范围变更规则；未完成工作重新评估，不默认结转。
- 调整后用后续一到两个迭代的完成率与偏差率验证，并把容量核对固定进计划会与回顾会。
先界定症状：排满与交付不足的具体表现
“排满”和“交付不足”是两种可以分开观察的现象。计划容量排满，指的是迭代计划会上把可用人力全部填入了工作项，承诺点数或工时接近甚至等于名义容量；实际完成量不足，指的是迭代结束时完成的工作项少于承诺，或者完成的工作项需要延期、拆分、转交。两者同时出现，才构成需要排查的容量估算偏差。如果计划本身留有余量而完成仍然不足，问题更可能出在执行环节；如果计划排满且完成率长期偏低，容量口径就是首要怀疑对象。
排查前先确定数据采集口径。建议以单个迭代为最小样本，连续采集两到三个迭代，避免用一次异常迭代下结论。每个迭代记录以下字段：
- 承诺量：迭代计划会上确认的故事点总数或工时总数，注明单位。
- 实际完成量：迭代结束时验收通过的工作项对应的点数或工时。
- 未完成工作项清单及原因：区分需求变更、估算偏小、阻塞等待、人力被占用、返工等。
- 迭代中范围变化：新增需求数量、移除需求数量、优先级调整导致的工作切换。
- 实际可用人力：参与迭代的成员、各自投入天数、请假与支持事务占用。
把这些字段放进同一张对比表，先算两个数：完成率（实际完成量÷承诺量）和偏差率（承诺量−实际完成量）÷承诺量。完成率连续两三个迭代低于团队历史水平，且未完成原因集中在少数几类，就可以进入原因验证。症状清单的作用是让后续排查有据可依，避免把“感觉排得太满”直接当成结论。
容量估算偏差的常见原因与验证证据
容量估算偏差通常来自四类原因：人员可用性口径、估算单位口径、范围变动、执行损耗。四类原因可能同时存在，排查时按顺序逐层验证，每层用数据确认或排除，避免同时调整多个变量导致无法归因。
| 原因类别 | 典型表现 | 验证证据 | 排除方法 |
|---|---|---|---|
| 人员可用性口径 | 按名义人数×迭代天数计算容量，未扣除会议、支持答疑、休假、并行任务 | 对比名义工时与实际投入工时；统计成员在迭代中被非交付事务占用的天数 | 若实际投入明显低于名义值，且缺口与未完成量大致对应，可确认此项为主因 |
| 估算单位口径 | 故事点与工时混用；把历史速率直接当作计划容量上限填满 | 检查工作项估算字段是否统一；对比历史速率与本次承诺量 | 若承诺量接近历史最高速率而非平均速率，或同一迭代内两种单位并存，可确认口径问题 |
| 范围变动 | 迭代中插入需求、优先级调整，容量未预留缓冲 | 统计迭代中新增与变更的工作项及其点数或工时 | 若新增量占承诺量比例较高且未从原计划中移除等量工作，可确认范围失控 |
| 执行损耗 | 返工、阻塞等待、跨团队依赖等待消耗容量但不产出可交付工作项 | 记录阻塞时长、返工工作项数量、依赖等待天数 | 若未完成工作项集中在被阻塞或返工的部分，可确认损耗占比过高 |
排查顺序建议从人员可用性开始。这一层的数据最容易采集，也最常被忽略：名义人力乘以迭代天数得到的工时，需要扣除站会、评审、答疑支持、休假和并行任务占用，剩下的才是可承诺容量。如果可承诺容量只有名义容量的六七成，而计划仍按名义值排满，偏差就有了直接解释。
第二层核对估算单位。故事点衡量相对规模，工时衡量时间投入，两者混用会让容量对比失去意义。历史速率反映的是过去实际完成能力，可以作为参考上限，直接把它当作计划容量填满，等于假设每个迭代都达到历史最好水平。验证方法是看承诺量是否长期贴着历史峰值，以及同一迭代内是否存在点数与工时并存的估算字段。
第三层核对范围变动。迭代中插入需求本身不一定有问题，问题在于插入后没有从原计划中移除等量工作，也没有预留缓冲。统计新增工作项占承诺量的比例，如果这个比例稳定存在，说明容量规则缺少对变动的处理。
第四层核对执行损耗。返工和阻塞等待会占用成员时间却不产生可交付成果。把未完成工作项按原因分类，如果集中在被依赖阻塞或反复返工的部分，说明容量估算没有为这类损耗留出空间。四层验证完成后，通常能确定一到两个主因，其余因素作为次要影响记录。
按排查顺序处置：从数据核对到规则调整
确认主因后，处置按四步推进，每步明确做什么、由谁做、达到什么条件再进入下一步。
第一步，核对历史速率与实际完成。由迭代负责人或项目经理整理最近三到六个迭代的承诺量、完成量和完成率，算出平均完成率和波动范围。这一步的产出是一张基线表，用来判断本次偏差是系统性偏高还是个别迭代波动。如果完成率长期在七成左右，说明计划容量需要整体下调；如果只有个别迭代偏低，先查该迭代的特殊事件。
第二步，按人员可用性重算容量。由各成员在计划会前提交本迭代可投入天数，扣除已知的休假、支持排班和并行任务，汇总得到可承诺容量。计划容量与可承诺容量分开记录：计划容量用于观察团队负荷，可承诺容量用于确定本次能接多少工作。两者差距过大时，优先按可承诺容量排入工作项。
第三步，统一估算单位。团队选定一种主单位，故事点或工时择一，另一种只作为辅助参考，不参与容量加总。如果保留工时统计，明确它用于估算任务持续时间，不与点数直接换算。统一单位后，历史速率才有可比性。
第四步，设定范围变更规则。明确迭代中插入需求的入口和条件：新增工作项需要说明来源和优先级，插入时同步评估是否需要移出等量原有工作，或动用预留缓冲。预留比例根据历史变动统计确定，不凭感觉设定。
处置过程中有一条风险边界需要守住：迭代未完成的工作项不默认自动结转到下一个迭代。未完成工作应重新评估规模、优先级和依赖关系，再决定是放回待办列表、拆分后重新排入，还是取消。自动结转会让下一个迭代的容量在开始前就被占用，偏差继续累积。
在工具承载上，ONES 支持团队围绕需求、工作项、迭代和项目进度开展协作，成员可以了解当前工作、优先级和交付目标；团队可结合自身节奏规划迭代、安排工作事项并跟踪推进状态，需求和相关任务可规划至迭代并分配负责人。ONES Project 提供任务工时统计用于估算任务持续时间，看板与燃尽图用于实时掌控进度。这些记录方式能让承诺量、实际完成和范围变动留在同一处，便于按上述步骤核对。容量计算和超载预警是否需要额外配置，建议在选型或实施时向厂商确认。
验证恢复与防止复发
调整是否生效，用后续一到两个迭代的数据验证。观察三个指标：完成率是否回到团队可接受区间并保持稳定；偏差率是否收窄，即承诺量与完成量的差距不再持续扩大；迭代中范围变动的比例是否被预留缓冲覆盖。如果调整后第一个迭代完成率明显回升，第二个迭代仍能保持，可以认为容量口径的修正起了作用。只回升一个迭代就回落，需要检查是否又回到了按名义容量排满的习惯。
防止复发靠固定动作，而不是一次性修正。把容量核对纳入迭代计划会的固定议程：会前收集成员可投入天数，会上先确认可承诺容量，再排入工作项，承诺量不超过可承诺容量。把偏差复盘纳入迭代回顾会的固定议程：对照承诺量、完成量和未完成原因，记录本次偏差的主要来源。范围变更和容量预留的使用情况持续记录，形成可查的历史，下次设定预留比例时有据可依。
偏差反复出现时，需要升级判断。如果连续三个以上迭代完成率持续偏低，且人员可用性和估算单位都已核对无误，问题可能超出容量估算本身，涉及需求优先级频繁变动、跨团队依赖长期未解或人员配置不足。这时应把数据提交给项目负责人或研发管理者，讨论范围取舍和资源安排，而不是继续在估算公式上找答案。ONES 的燃尽图、工时日志等报表可用于复盘迭代进度、质量和成本偏差，为这类讨论提供记录依据；具体报表的指标口径以实际配置为准。
常见问题
迭代计划时按名义人力排满，为什么完成率长期只有七成左右？
名义人力乘以迭代天数得到的是理论工时，实际可投入的交付时间还要扣除站会、评审、答疑支持、休假和并行任务占用。如果计划一直按理论值排满，可承诺容量只有名义容量的六七成，完成率自然会稳定在相近水平。
验证方法是让成员在计划会前提交本迭代可投入天数，汇总后与名义工时对比。缺口与未完成量大致对应时，就可以把容量口径作为主因，按可承诺容量重新排入工作项。
历史速率能不能直接当作下个迭代的容量上限？
历史速率反映的是过去实际完成能力，可以作为参考，直接当作计划容量填满，等于假设每个迭代都达到历史最好水平。承诺量长期贴着历史峰值，偏差就会反复出现。
更稳妥的做法是用最近几个迭代的平均完成率作为基线，结合本迭代的人员可用性调整，再确定承诺量。个别迭代有特殊事件时，单独记录原因，不并入基线。
迭代中插入需求很常见，容量上应该怎么处理？
插入需求本身不一定有问题，问题在于插入后没有从原计划中移除等量工作，也没有预留缓冲。可以先统计最近几个迭代新增工作项占承诺量的比例，据此设定预留比例，不凭感觉决定。
同时明确插入的入口和条件：新增工作项说明来源和优先级，插入时同步评估是否移出等量原有工作或动用预留。这样范围变动有记录，下次设定预留时也有依据。
未完成的工作项可以直接结转到下一个迭代吗？
不建议默认自动结转。未完成工作会占用下一个迭代的容量，如果直接带入，新迭代在开始前就已超载，偏差会持续累积。
更合适的做法是重新评估未完成工作项的规模、优先级和依赖关系，再决定放回待办列表、拆分后重新排入，还是取消。这个判断放在迭代回顾会上做，与偏差复盘一起完成。
调整容量规则后，怎么判断是否真的生效？
用后续一到两个迭代的数据验证，观察三个指标：完成率是否回到团队可接受区间并保持稳定；偏差率是否收窄；迭代中范围变动是否被预留缓冲覆盖。
如果第一个迭代回升、第二个迭代仍能保持，可以认为修正起了作用。只回升一个迭代就回落，需要检查是否又回到按名义容量排满的习惯。连续三个以上迭代仍偏低，且人员可用性和估算单位都已核对，应把数据提交给项目负责人讨论范围取舍和资源安排。
