迭代容量与实际交付偏差大，先不要急着改估算方法。更常见的做法是先固定统计口径，把偏差拆成“容量估算不准”和“执行过程损耗”两部分，再用连续两三个迭代的数据逐项验证。本文按“确认现象—列出假设—用证据排查—分类处置—验证恢复”的顺序，给出一套可落地的诊断路径。
要点总览（TL;DR）
- 诊断偏差先固定统计口径：明确按故事点还是工时、按承诺范围还是最终范围、以什么状态算完成，再用连续两到三个迭代的数据比较。
- 偏差通常来自四类因素：容量口径未扣除请假与支持性工作、估算基准漂移或任务粒度过大、迭代内插单与依赖阻塞、完成定义不清导致评审测试积压。
- 排查顺序建议先核对容量明细排除假偏差，再量化范围变化，最后检查估算基准与任务流转中的等待占比。
- 处置时一次只调整一类变量并设定两到三个迭代的观察期；未完成工作重新评估后进入后续排期，不默认自动结转。
- 用后续迭代的偏差率、范围变更比例和阻塞时长验证恢复效果，并把容量口径与估算基准检查写入迭代复盘。
先确认偏差的表现与统计范围
“偏差大”本身不是可诊断的对象。容量估算偏高和偏低是两种不同症状，对应的原因和处置方向也不同。诊断第一步，是把模糊的感受转成可比较的具体现象。
容量估算偏高，典型表现是迭代排得很满、承诺量接近容量上限，但实际交付明显不足，未完成项集中出现在迭代末期。容量估算偏低，则表现为排期保守、团队有余量、交付稳定但资源利用率低，长期看需求消化速度慢于团队实际能力。两类症状要分开记录，避免混在一起得出“估算不准”的笼统结论。
统计口径需要在诊断开始前固定下来，至少明确三件事：
- 计量单位：按故事点还是按工时统计。两者不能混用，故事点用于相对规模，工时用于投入时间，混用会让偏差失去可比性。
- 范围基准：按迭代承诺范围统计，还是按最终实际范围统计。承诺范围反映计划准确性，最终范围反映真实产出，两个口径算出的偏差率含义不同。
- 完成定义：以什么状态算交付。是开发完成、测试通过，还是已上线。完成定义不统一，偏差会被系统性放大或缩小。
观察窗口建议取连续两到三个迭代。单个迭代受假期、线上故障、临时支持等偶发因素影响大，一次异常不足以支撑规律性判断。把这两三个迭代的容量、承诺量、实际完成量、范围变更量并列记录，形成一份偏差现象描述，后续所有排查都基于这份统一口径的数据展开。
按四类因素列出原因假设
口径固定后，下一步是把可能的原因列全，再逐项找证据。迭代容量与交付的偏差通常集中在四类因素，每类都有对应的可观察证据。
| 因素类别 | 典型假设 | 对应观察证据 |
|---|---|---|
| 容量口径 | 可用人力未扣除请假、会议、运维支持、跨团队协作时间；容量按满编计算 | 容量明细、实际出勤记录、会议与支持性工作的时间占用 |
| 估算与拆分 | 估算基准随人员或需求类型漂移；任务粒度过大难以判断大小；缺少技术预研导致低估 | 历史估算与实际耗时对比、任务拆分粒度、预研任务记录 |
| 范围变化 | 迭代内插单、需求变更、外部依赖阻塞造成等待 | 承诺范围与最终范围对比、变更记录、任务阻塞时长 |
| 完成定义 | 验收标准不清、评审与测试环节积压形成隐性瓶颈 | 任务在各状态间的停留时间、评审与测试队列长度 |
容量口径类假设最容易被忽略。团队按名义人数乘以工作日算出容量，实际可用时间却被会议、值班、跨团队支持切走一大块，容量从一开始就偏高。这类偏差看起来像“执行不力”，实质是分母算错了。
估算与拆分类假设关注的是估算基准是否稳定。同一类需求，不同人估出的点数差异大，或者任务拆到“做一个模块”这种粒度，都会让容量与交付失去可比性。缺少技术预研时，未知的技术风险在迭代内才暴露，也会表现为交付不足。
范围变化类假设需要用承诺范围和最终范围的差值来量化。插单和需求变更如果缺少准入条件，迭代内范围持续膨胀，容量不变而工作量增加，偏差自然出现。依赖阻塞造成的等待则要看任务在阻塞状态的停留时长。
完成定义类假设常被当作执行问题。验收标准模糊导致反复返工，或者测试环节排队，任务在“开发完成”和“已交付”之间长时间停留，统计口径若按最终交付计算，偏差就会被放大。这一阶段只列假设和证据来源，不下结论。
用数据逐项验证并排除假设
假设列全后，按“先口径、再范围、后估算与执行”的顺序排查，可以最快排除假偏差，避免在错误方向上调整方法。
第一步，核对容量明细与实际出勤。把迭代内每个成员的名义可用时间，减去请假、会议、支持性工作后的实际可用时间，重新计算容量。如果修正后的容量与承诺量差距明显缩小，说明偏差主要来自口径错误，属于假偏差，不需要改估算方法。这一步能排除相当一部分“看起来偏差大”的情况。
第二步，比对承诺范围与最终范围。统计迭代内新增、变更、移除的工作量，算出范围变化占承诺量的比例。范围变化比例高，说明偏差主要来自范围失控；比例低，则范围因素可以排除，继续往下查。
第三步，对照任务流转时间，判断等待与阻塞占比。看任务在阻塞、待评审、待测试等状态的停留时长占总周期的比例。等待占比高，说明瓶颈在协作与流转环节，而非估算本身。
第四步，检查估算基准是否漂移。把同类需求的历史估算与实际耗时并列，看偏差是否集中在特定人员、特定需求类型或特定时间段。基准漂移通常表现为系统性偏高或偏低，而不是随机波动。
排查完成后，输出一份带证据的结论：哪些原因已被数据排除，哪些原因有证据支持，哪些仍需下一个迭代继续观察。结论要区分“已确认”和“待确认”，避免把单次观察直接当成定论。
在记录容量明细、范围变更和任务流转数据时，ONES 可以承载部分管理动作：团队可结合自身节奏规划迭代、安排工作事项并跟踪推进状态，需求和相关任务可规划至迭代并分配负责人，任务工时统计用于估算任务持续时间，看板和燃尽图用于实时掌控进度。这些记录构成排查所需的基础数据；容量上限字段和范围变更的专门记录能力，官方资料未明确说明，选型时需另行核验。
针对确认原因安排处置动作
处置动作要对应已确认的原因，一次只调整一类变量，并给每项调整设定观察期，否则无法判断是哪项改动起了作用。
- 口径问题：在容量计算中补充请假、会议、支持性工作等明细字段，固定统计规则并写入团队约定。规则一旦确定，连续几个迭代不再变动，保证数据可比。
- 范围问题：明确迭代内变更的准入条件，例如插单需替换等量工作或经负责人确认；变更发生后重新评估剩余容量，而不是默认加班消化。
- 估算问题：统一估算基准，用历史同类需求校准；把过大任务拆到可在迭代内判断完成的程度；对技术不确定性高的需求，在排期前安排预研并单独计入容量。
- 执行问题：识别阻塞任务并设置升级路径，明确阻塞超过多长时间由谁介入协调；对评审和测试环节的积压设置队列上限。
未完成工作的处理需要单独说明。迭代结束时未完成的事项，应重新评估剩余工作量和优先级，再进入后续排期，不默认自动结转到下一个迭代。自动结转会让下一个迭代的容量被隐性占用，偏差继续累积，也会掩盖真实的交付能力。
调整估算方法或流程时要注意风险边界。一次性改动估算基准、拆分规则和容量口径，会让后续数据失去可比性，也无法判断效果。建议每个观察期只改一类变量，观察期取两到三个迭代，期间保持其他条件稳定。
验证恢复并防止偏差复发
处置是否生效，要用后续两到三个迭代的偏差率来验证。偏差率可按“实际完成量除以承诺量”计算，同时记录范围变更比例和阻塞时长占比，三者结合看，避免单一指标好转而其他问题被掩盖。
验证阶段需要保留三类记录作为复盘依据：容量明细，用于确认分母是否准确；范围变更记录，用于量化迭代内工作量波动；完成记录，用于确认完成定义是否被一致执行。这三类记录齐全，复盘时才能把偏差归因到具体环节。
复发预防可以落到迭代复盘的固定检查项：
- 本迭代容量计算是否包含请假、会议与支持性工作；
- 估算基准与上个迭代是否一致，有无未说明的调整；
- 迭代内变更是否经过准入确认并重新评估容量；
- 阻塞与等待时长是否在可接受范围，升级路径是否被触发。
同时设定偏差预警阈值，例如连续两个迭代偏差率超过约定范围，或范围变更比例超过约定上限时，触发专项复盘。阈值由团队根据自身节奏确定，写入迭代运行规则，避免每次靠感觉判断。迭代完成并发布后，可借助燃尽图、工时日志等数据报表复盘进度与成本偏差，把上述检查项固化为回顾会的常规内容，偏差诊断就从一次性排查变成了持续运行的机制。
常见问题
迭代容量估算偏高和偏低，排查重点有什么不同？
估算偏高通常表现为承诺量贴近容量上限但交付不足，排查重点在容量分母是否算多了，以及迭代内范围是否膨胀；估算偏低表现为排期保守、团队长期有余量，排查重点在估算基准是否系统性偏大、任务拆分是否过粗。两类症状要用同一套口径分别记录，混在一起容易得出“估算不准”的笼统结论，反而找不到具体环节。
团队人数没变，为什么容量口径仍然会出错？
容量按名义人数乘工作日计算时，请假、会议、值班、跨团队支持和运维工作都没有被扣除，分母从一开始就偏大。人员流动、兼职投入比例变化、新成员上手期也会让实际可用时间与名义时间产生差距。核对容量时，把每个成员的实际可用时间单独列出来，与承诺量重新比对，往往能解释相当一部分偏差。
迭代内插单造成的偏差，怎么和估算不准区分开？
用承诺范围与最终范围的差值来量化。统计迭代内新增、变更、移除的工作量，算出它占承诺量的比例。比例高，偏差主要来自范围变化，此时调整估算方法收效有限；比例低，范围因素可以排除，再去看估算基准和任务流转中的等待。两种原因可能同时存在，排查时先量化范围影响，再看剩余偏差能否由估算解释。
未完成的工作可以直接结转到下一个迭代吗？
建议重新评估后再排期，不默认自动结转。直接结转会让下一个迭代的容量被隐性占用，新承诺的工作与遗留工作叠加，偏差继续累积，也会掩盖团队真实的交付能力。重新评估的内容包括剩余工作量、优先级是否仍然成立，以及是否需要拆分或补充预研。
调整估算方法后，多久能判断是否有效？
观察期建议取两到三个迭代。单个迭代受假期、线上故障等偶发因素影响大，不足以判断趋势。观察期内保持其他条件稳定，一次只改一类变量，例如先统一估算基准，暂不动容量口径和拆分规则，否则无法判断是哪项调整起了作用。验证时同时看偏差率、范围变更比例和阻塞时长，避免单一指标好转而其他问题被掩盖。
