迭代容量估算偏高，常见两种后果：承诺的工作量超出团队实际可交付能力，导致延期和加班；或为了“保险”压低承诺，造成人员和环境闲置。本文给出一套可执行的方法：用历史速率、成员可用性和外部依赖三类输入算出基准容量，经四步流程形成可承诺区间，再按取舍规则承诺工作量，并在迭代中调整、在迭代后复盘。
要点总览（TL;DR）
- 容量估算需要三类输入：近3–6个迭代已完成工作项的中位数速率、逐人折算的有效人天、单独列出的外部依赖与固定占用。
- 四步流程把输入转成可承诺区间：历史速率定基准、有效人天比例修正、扣除依赖得净容量、设置缓冲形成下限与上限。
- 承诺取区间下限附近，上限留给迭代中插入的紧急事项；高不确定性工作项单独标注并预留探索容量。
- 迭代过半做剩余容量与剩余工作量比对，阻塞或依赖延期时重算容量；未完成项重新估算并重新排序，不默认结转。
- 用检查清单核对输入口径、承诺区间、调整留痕，出现阻断项先补齐输入再确认承诺。
先算清三类输入：历史速率、成员可用性、外部依赖
容量估算失真的根源通常是输入不完整：只凭成员人数乘天数，或只参考上一个迭代的完成量。把输入拆成历史速率、成员可用性、外部依赖三类分别取数，容量才有可核对的基础。
历史速率：按已完成工作项统计，取中位数
历史速率的口径要固定：只统计迭代内已完成并满足验收标准的工作项，未完成项和返工部分不计入。取近3–6个迭代的数据，用中位数而非平均值。平均值容易被个别异常迭代拉高或拉低，中位数更能代表团队的常态产出。如果团队刚组建或工作项粒度变化较大，历史速率的参考价值下降，需要在估算时明确标注这一限制。
成员可用性：从名义人天折算有效人天
名义人天是成员在迭代内的日历工作日，有效人天要扣除假期、会议、支持值班、培训以及部分投入角色的比例。折算时逐人记录名义人天、扣除项和有效人天，避免只报一个总数。部分投入的角色（如兼职测试、共享的设计资源）按实际投入比例折算，不按满员计算。
外部依赖与固定占用：单独列出并扣除
等待第三方接口联调、环境准备、外部评审、跨团队交付的时间，属于团队无法自主支配的占用。这类时间要单独列成清单，注明依赖对象、预计等待时长和责任人，并从容量中扣除。把等待时间当作可工作时间，是承诺过载的常见来源。
| 输入类别 | 取数口径 | 记录责任人 | 更新时点 |
|---|---|---|---|
| 历史速率 | 近3–6个迭代已完成工作项的中位数，剔除未完成与返工 | 迭代负责人 | 每个迭代回顾会后 |
| 成员可用性 | 名义人天扣除假期、会议、值班、培训，按投入比例折算 | 团队成员自报，迭代负责人汇总 | 迭代规划会前 |
| 外部依赖与固定占用 | 逐项列出依赖对象、等待时长、责任人 | 产品负责人与迭代负责人共同确认 | 迭代规划会前，迭代中如有变化即时更新 |
从基准容量到可承诺区间：四步估算流程
三类输入齐备后，按以下四步把数据转化为可承诺的工作量区间。每一步都有明确的输入、动作、输出和完成标志，便于在规划会上逐步推进。
第一步：用历史速率中位数确定基准容量
输入是近3–6个迭代的速率数据，动作是取中位数，输出是一个以工作项估算单位表示的基准容量。完成标志是团队对该数值的来源和口径无异议。若历史数据不足，可用最近一个迭代的数据并标注不确定性。
第二步：按有效人天比例修正基准容量
输入是基准容量和本迭代的有效人天与上一参照期有效人天的比值，动作是按比例修正，输出是修正后的容量。例如参照期有效人天为40，本迭代为32，则容量按0.8修正。完成标志是修正系数有书面记录，团队成员知晓折算依据。
第三步：扣除外部依赖与固定占用，得到净容量
输入是修正后的容量和依赖扣除清单，动作是逐项扣除等待与占用时间对应的估算量，输出是净容量。完成标志是每一项扣除都有对应条目和责任人，没有笼统的“预留一部分”。
第四步：设置缓冲比例，形成下限—上限区间
输入是净容量，动作是按团队风险状况设置缓冲比例，输出是可承诺区间的下限与上限。缓冲用于吸收估算误差、紧急插入事项和依赖波动。完成标志是区间上下限均写入容量表，并在规划会上向团队说明。
承诺时如何取量：避免过载与浪费的取舍规则
有了区间，承诺取量仍需规则约束。核心原则是承诺取区间下限附近，把上限空间留给迭代中插入的紧急事项。这样既控制过载风险，也避免把容量全部填满后无法应对变化。
- 按下限承诺：规划会确定的范围以区间下限为基准，上限作为可吸收的弹性空间，不提前分配。
- 拆分工作项粒度：单个工作项的估算不宜过大，避免一个大项吃掉全部容量、挤压其他事项的调整空间。
- 标注高不确定性项：技术方案未定、依赖外部接口、需求边界模糊的工作项单独标注，并预留探索容量，不与确定项混在一起承诺。
| 偏差类型 | 早期信号 | 应对方向 |
|---|---|---|
| 承诺过载 | 规划会即出现“先接下来再说”；迭代前期看板在制品堆积；依赖项等待时间未计入 | 回退到区间下限，重新核对依赖扣除项 |
| 容量浪费 | 迭代中后期成员频繁等待任务；上限空间从未被使用；承诺量长期显著低于历史速率 | 检查是否过度保守，适度上调承诺至区间中部 |
迭代中的容量调整与未完成项处理
规划期的区间不是一成不变。迭代进行中要按实际消耗比对剩余容量与剩余工作量，在中期节点触发调整，而不是等到迭代结束才发现偏差。
中期比对与调整时点
建议在迭代过半时做一次剩余容量与剩余工作量的比对。若剩余工作量明显超出剩余容量，或出现阻塞导致可用时间减少，就触发容量重算。重算仍沿用规划期的口径：更新有效人天、更新依赖扣除项，得出新的剩余容量。
阻塞与依赖延期的处理
依赖延期时，把受影响的工作项从当前承诺中移出或降级，同时更新容量表。阻塞未解除前，不把相关工作量计入可完成范围。调整结果要在看板和容量表中同步体现。
未完成项重新评估而非默认结转
迭代结束时未完成的工作项，不默认自动进入下一迭代。处理方式是重新估算剩余工作量、重新确认优先级，再决定是否纳入下一迭代的承诺范围。这样既避免未完成项悄悄占用新容量，也让速率统计保持准确。
调整记录要留痕：记录触发原因、调整前后的容量与范围、决策人。这些记录是下一迭代速率统计和回顾会的输入。在ONES中，团队可以用子任务拆分需求、用敏捷看板跟踪任务状态，并通过燃尽图和工时日志观察进度偏差，为容量重算提供依据。
角色分工与交付物
容量估算与承诺涉及三类角色，职责和交付物需要提前明确，避免规划会上临时拼凑数据。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 产品负责人 | 确定优先级与范围取舍，确认依赖清单 | 按优先级排序的候选工作项、范围取舍结论 | 规划会前 |
| 迭代负责人 | 组织估算、维护容量表、跟踪偏差与调整记录 | 容量输入表、可承诺区间、调整记录 | 规划会前完成输入，迭代中持续更新 |
| 团队成员 | 提供可用性与工作量估算输入，标注不确定性 | 个人有效人天、工作项估算与风险标注 | 规划会前提交，迭代中反馈实际消耗 |
产品负责人根据优先级把待办需求规划到迭代，团队在计划会议上共同评审需求与验收标准，再由设计、研发、测试人员拆分子任务。这一流程在ONES的迭代规划场景中有对应支持，容量表本身可按团队习惯用文档或表格维护。
一个迭代规划会的容量估算示例
以下为演示情景，数字用于说明方法，不代表任何真实团队数据。
某团队近5个迭代的已完成工作项估算值分别为42、38、45、40、39点，中位数为40点，作为基准容量。参照期有效人天合计50，本迭代因两人各休假两天、一场全天评审，有效人天折算为40，修正系数0.8，修正后容量为32点。外部依赖清单中，第三方接口联调预计等待3天，折合4点，从容量中扣除，净容量为28点。按20%缓冲设置，可承诺区间为下限22点、上限28点。
规划会上，产品负责人按优先级选取估算合计约22点的工作项作为承诺范围，其中包含一个技术方案未定的高不确定性项（估算5点），单独标注并预留探索时间。上限空间不提前分配，留给迭代中可能插入的紧急事项。这个示例的可迁移规律是：每一步都有明确输入和折算依据，承诺取区间下限，缓冲和不确定性单独管理。
完成检查：容量估算是否可复用的核对项
迭代规划结束后，用以下清单逐项核对，判断本次容量估算与承诺是否达到可复用标准。
- 历史速率是否按已完成工作项统计，是否剔除未完成与返工，是否采用3–6个迭代的中位数。
- 成员可用性是否逐人折算，假期、会议、值班、部分投入比例是否有记录。
- 外部依赖与固定占用是否单独列项，是否有责任人和预计时长。
- 承诺工作量是否落在可承诺区间内，是否以下限附近为基准。
- 高不确定性工作项是否单独标注并预留探索容量。
- 迭代中是否做过剩余容量与剩余工作量的中期比对，调整是否有记录。
- 未完成项是否重新估算并重新排序，而非默认结转。
- 容量表与调整记录是否可回溯，能否作为下一迭代速率统计的输入。
阻断项包括：历史速率口径不一致、依赖扣除无清单、承诺量超出区间上限。出现任一阻断项时，应先补齐输入再确认承诺，避免把偏差带入迭代执行。上述核对项与调整记录在ONES的迭代回顾中可与燃尽图、工时日志等报表结合使用，帮助团队判断容量估算是否需要修正。
常见问题
团队历史数据不足3个迭代，容量估算还能做吗？
可以做，但要降低结论的确定性。可先用最近一个迭代的已完成工作项作为基准，并在容量表上标注“样本不足、参考价值有限”。同时把缓冲比例适当放大，承诺时更靠近区间下限。等积累到3个以上迭代数据后，再改用中位数口径，并回看前几次估算的偏差，逐步校准。
迭代中途插入紧急需求，容量已经按区间下限承诺，怎么处理？
先判断插入项是否必须在本迭代完成。若必须，从当前承诺中移出等量的低优先级工作项，保持承诺总量不突破区间上限，而不是简单叠加。移出的工作项重新评估后回到待办列表排序。若插入项可以延后，放入下一迭代候选范围。无论哪种处理，都要在容量表和调整记录中写明触发原因、移出项和决策人。
成员可用性按人折算后，团队总容量是否直接相加？
逐人折算得到的是个人有效人天，但团队总容量不能简单相加后全部用于承诺。团队协作中存在评审、联调、知识传递等共同占用，且成员之间技能不完全可替代。建议在逐人折算的基础上，再按团队实际情况扣除一部分协作占用，或把这部分放入缓冲统一管理。关键是折算口径前后一致，便于跨迭代比较。
未完成工作项重新评估时，原估算还有参考价值吗？
有参考价值，但不能直接沿用。重新评估时先看原估算与实际已投入的差距，判断偏差来自估算不准、需求变更还是阻塞等待。然后只对剩余部分重新估算，并重新确认优先级：有些项在延期后可能已不再重要，应回到待办列表重新排序，而不是默认进入下一迭代承诺。重新评估的结果和原因要记录，作为后续估算校准的依据。
容量估算和承诺的记录，在ONES里怎么落地？
ONES 支持产品负责人按优先级把待办需求规划到迭代，并在迭代计划会议上与团队共同评审需求与验收标准；设计、研发、测试人员可用子任务拆分需求，便于跟踪。迭代过程中可通过敏捷看板管理任务状态，结合燃尽图、工时日志等报表观察进度偏差，为容量重算和回顾提供数据。容量表本身可按团队习惯用文档或表格维护，具体字段与统计口径以实际配置为准。
