迭代规划容量失真，指的是规划时依据的“可用投入”与迭代实际执行条件脱节，导致承诺量长期高于完成量。它常出现在规划会变成任务分派或估算争论时。本文从可对照的症状入手，按假设与证据排查原因，再判断规划缺失了哪类输入，并给出恢复验证与复发预防的做法。
要点总览（TL;DR）
- 容量失真的典型信号：规划会退化为任务分派、估算争论反复、承诺量长期高于完成量、计划容量与成员实际可用时间脱节。
- 常见原因包括缺少历史速率与可用工时基线、估算口径混用、未扣除休假与支持性工作、需求拆分粒度失衡、外部插入缺少缓冲。
- 判断规划缺失的输入，重点看产能基线、估算口径、可用时间假设、缓冲规则四项是否在会前准备、会上确认。
- 补齐输入按顺序推进：先统一估算口径，再建立产能基线，然后收集可用时间假设，最后设定缓冲规则。
- 恢复验证看承诺与完成偏差是否收窄、估算偏差是否缩小；未完成工作应重新评估优先级与工作量，而非默认结转。
容量失真在迭代规划中有哪些典型表现
判断是否属于容量失真，可以看规划会与迭代执行中是否同时出现以下几类现象。单次延期更可能是执行问题；多种现象反复出现，才说明规划所依据的容量假设本身不可靠。
- 规划会退化为任务分派。会议大部分时间用于把需求逐条派给个人，缺少“这个迭代团队能承担多少”的容量讨论，也没有对可用时间、休假、支持性工作的确认环节。
- 估算争论反复出现且口径不一致。同一类需求在不同迭代被估成差异很大的数字，讨论焦点集中在“这个到底算几点/几天”，而非需求范围与验收标准。
- 迭代内任务持续溢出。承诺量长期高于完成量，迭代结束时有大量工作被移到下一个迭代，且溢出比例在多个迭代间保持稳定，说明偏差来自规划而非偶发干扰。
- 计划容量与成员实际可用时间明显脱节。规划按满员满工时计算，实际执行中成员被会议、线上支持、临时插入需求占去大量时间，计划数字从迭代第一天起就偏高。
- 规划结论缺乏可核对依据。容量数字来自感觉或上一迭代的承诺量，而非历史完成量或可用工时记录，会上无人能说明这个数字是怎么算出来的。
如果上述现象中同时出现三条以上，并且跨越两个以上迭代，就可以按容量失真来处理，而不必先归因为成员投入度或执行力问题。
容量失真的原因假设与排除证据
容量失真的原因需要用数据验证，不能凭会议上的印象下结论。下面按证据可得性排列常见假设，并给出对应的验证方式与排查顺序。
| 原因假设 | 可观察迹象 | 验证证据 |
|---|---|---|
| 缺少历史速率与可用工时基线 | 容量数字无来源，每迭代重新“拍”一个数 | 对比近几个迭代的承诺量与完成量，看是否存在稳定可参考的完成量区间；核对是否有可用工时记录 |
| 估算口径不统一 | 故事点、人天、小时混用，同一需求换人估算差异大 | 抽取若干需求，比较不同成员的估算值与实际投入，看偏差是否集中在单位换算上 |
| 未扣除休假、会议、支持性工作与外部插入 | 计划按满员计算，执行中频繁被占用 | 用工时日志或日历记录统计成员实际可投入时间，与规划假设对比 |
| 需求拆分粒度失衡 | 部分需求过大无法估准，部分需求过细导致管理开销上升 | 统计迭代内需求的规模分布，对比大颗粒需求与小颗粒需求的估算偏差 |
| 外部插入缺少缓冲 | 迭代中途不断加入新需求，原计划被挤压 | 记录迭代内新增工作的数量与工时占比，看是否超出预留空间 |
排查顺序建议从证据最容易获得的一项开始：先看历史承诺量与完成量的偏差，确认是否存在系统性高估；再检查估算口径是否统一，因为口径混用会让后续所有容量数字失去可比性；最后核对可用时间假设与缓冲规则。每排除一项假设，都应留下对应的数据记录，避免下一轮规划又回到凭感觉判断。
需要区分的是，估算偏差可能来自需求理解不足，也可能来自口径混用。前者表现为个别需求偏差大，后者表现为整体数字系统性偏移。用估算偏差对比可以把两者分开：若偏差集中在特定类型需求，优先检查需求澄清；若偏差普遍存在，优先统一估算口径。
规划过程缺失了哪类输入
容量失真的直接原因是规划会缺少可核对的输入。判断规划是否缺失输入，重点看四项内容是否在会前准备、会上确认：产能基线、估算口径、可用时间假设、缓冲规则。缺其中任何一项，容量数字都会变成讨论中的主观判断。
四类输入的具体内容
- 产能基线：基于历史完成量形成的团队可承担工作量参考区间，而不是上一迭代的承诺量。
- 估算口径：团队约定的单一主估算单位及换算说明，确保故事点、人天、小时不会在同一张计划里混用。
- 可用时间假设：扣除休假、会议、支持性工作后的成员实际可投入时间，需在规划前收集并写入计划。
- 缓冲规则：为外部插入、线上问题等预留的容量比例，以及超出缓冲时的处理方式。
按优先级补齐输入的处置步骤
- 先统一估算口径。团队选定一种主口径，明确其他单位的换算方式，并在需求描述中标注。完成标志是同一需求由不同成员估算时，差异落在可接受范围内。
- 再建立产能基线。取近几个迭代的完成量，剔除异常迭代后形成参考区间。完成标志是规划会上能直接引用这个区间，而非重新争论总量。
- 收集可用时间假设。会前让成员提交本迭代的休假、会议与支持性工作占用，汇总为可投入时间。完成标志是计划容量与汇总后的可用时间一致。
- 设定缓冲规则。约定预留比例与触发条件，并记录迭代内实际插入的工作。完成标志是外部插入有据可查，超出缓冲时有明确的取舍动作。
规划会中的角色分工与交付物
产品负责人按优先级把需求规划到对应迭代，并在计划会议上与团队共同评审需求；设计、研发、测试人员在需求与验收标准达成一致后，用子任务拆分需求，便于后续跟踪。规划会的交付物应包括：本迭代承诺的需求清单、统一的估算结果、可用时间汇总、缓冲预留说明。团队在迭代中围绕这些需求完成自己拆解的任务，并通过看板管理任务状态。
在工具承载上，ONES 支持产品负责人按优先级将需求规划至迭代，并在计划会议中与团队评审需求；需求与验收标准确认后，成员可用子任务拆分需求；迭代过程中通过敏捷看板管理任务状态，任务工时统计可用于估算任务持续时间。这些能力对应的是规划输入的记录与传递，容量基线区间和缓冲比例仍需团队结合自身历史数据确定。
调整前的条件与停止点
在改动估算口径或产能基线前，应先保留至少两个迭代的历史数据作为对照，避免新旧口径混在一起无法比较。若团队同时面临需求范围大幅变化或人员结构调整，容量基线需要重新采集，此时不宜直接套用旧区间。出现承诺量连续两个迭代仍显著高于完成量、且原因无法定位时，应暂停扩大承诺量，先回到输入核对环节。
如何验证容量恢复并防止复发
容量是否恢复，要看承诺与完成之间的偏差是否收窄，而不是看某一个迭代是否顺利完成。验证应覆盖指标、未完成工作的处理、复盘节奏三个层面。
验证指标
- 承诺量与完成量偏差：连续多个迭代的完成量落在承诺量的合理区间内，偏差趋势收窄而非反复波动。
- 估算偏差趋势：同类需求的估算值与实际投入差距逐步缩小，且偏差不再集中出现在某一类需求上。
- 可用时间吻合度：规划时的可用时间假设与迭代中实际投入时间基本一致。
未完成工作的处理
迭代未完成的工作应在下个迭代重新评估优先级与工作量，而不是默认结转到下一迭代的承诺量中。默认结转会把上一迭代的偏差带入新规划，持续虚增容量。重新评估时需确认该工作是否仍然必要、范围是否变化，再决定是否纳入新承诺。
复盘节奏与基线更新
每个迭代结束后，用燃尽图、工时日志等数据复盘进度与偏差，讨论改进建议；每若干个迭代根据最新完成量更新产能基线区间，使基线跟随团队实际能力变化。ONES 的迭代回顾可借助燃尽图、工时日志等报表复盘进度、质量与成本偏差，燃尽图也可用于评估当前研发效率，为基线更新提供数据参考。
复发预警信号
- 规划会再次以任务分派为主，容量讨论被压缩或省略。
- 估算争论重新集中在单位换算上，而非需求范围。
- 连续两个迭代出现较大比例的工作结转。
- 迭代中途插入工作明显增多，缓冲规则被绕过。
出现上述信号时，应回到输入核对环节，检查产能基线、估算口径、可用时间假设与缓冲规则是否仍然有效，而不是等到承诺量再次失控后再处理。
常见问题
规划会已经按历史完成量定了容量，为什么迭代中还是频繁溢出？
历史完成量只解决了“团队过去能做多少”这一项输入，还需要核对另外三项：估算口径是否统一、可用时间假设是否扣除了休假与支持性工作、是否为外部插入预留了缓冲。若计划容量按满员满工时计算，而迭代中成员被会议、线上支持和临时需求占去大量时间，即使基线数字本身准确，承诺量仍会偏高。建议在规划前汇总成员本迭代的实际可投入时间，与产能基线对照后再确认承诺量。
团队同时用故事点和人天估算，是否一定会导致容量失真？
两种单位并存本身不必然出问题，风险在于同一张计划里混用且没有换算说明。此时容量数字失去可比性，估算争论容易集中在单位换算而非需求范围上。可行的做法是约定一种主估算单位，明确其他单位的换算方式，并在需求描述中标注。判断口径是否统一，可以抽取若干需求比较不同成员的估算值与实际投入，看偏差是否集中在单位换算上。
迭代未完成的工作，直接带到下个迭代继续做有什么问题？
默认结转会把上一迭代的偏差带入新规划，使下一迭代的承诺量持续虚增，容量失真被掩盖而不是被修正。更稳妥的做法是在下个迭代重新评估该工作的优先级与工作量，确认是否仍然必要、范围是否变化，再决定是否纳入新承诺。连续两个迭代出现较大比例结转，本身就是容量失真的预警信号，应回到输入核对环节检查产能基线、估算口径、可用时间假设与缓冲规则。
团队人员或需求范围发生较大变化时，容量基线还能沿用吗？
人员结构调整或需求范围大幅变化时，旧的产能基线参考价值下降，需要重新采集。调整估算口径或基线前，建议保留至少两个迭代的历史数据作为对照，避免新旧口径混在一起无法比较。若承诺量连续两个迭代仍显著高于完成量且原因无法定位，应暂停扩大承诺量，先回到输入核对环节，而不是继续按旧区间排计划。
规划会中产品负责人和研发测试人员分别负责哪些交付物？
产品负责人按优先级把需求规划到对应迭代，并在计划会议上与团队共同评审需求；设计、研发、测试人员在需求与验收标准达成一致后，用子任务拆分需求，便于后续跟踪。规划会的交付物应包括本迭代承诺的需求清单、统一的估算结果、可用时间汇总和缓冲预留说明。ONES 支持产品负责人按优先级将需求规划至迭代并在计划会议中评审，需求确认后成员可用子任务拆分，迭代中通过敏捷看板管理任务状态，任务工时统计可用于估算任务持续时间。
