迭代容量估算要用三类输入：最近几个迭代的实际完成量、本迭代成员的真实可用投入，以及外部依赖和风险带来的扣减。先把历史速率算成区间，再把人员可用性折算成可用人天，最后扣减依赖与缓冲，得到可承诺容量。承诺时取区间下沿，把上限留作争取空间，避免按最好情况承诺导致过载。
要点总览（TL;DR）
- 历史速率只统计迭代内实际完成的工作项，取最近3–6个迭代，剔除异常迭代后用中位数加波动范围表达为区间，单位跨迭代保持统一。
- 成员可用性按人折算可用天数，扣除假期、培训、支持值班等占用，部分投入成员按比例折算，新人按上手程度打折，并写明换算假设。
- 在速率区间和可用投入基础上扣减外部依赖等待时间、设置风险缓冲，得到可承诺容量区间；承诺取区间下沿，上限作为争取空间。
- 迭代中容量变化按触发条件记录，未完成工作重新评估后再决定去向；迭代后对比承诺与实际，把偏差原因用于修正下轮估算。
先算历史速率：从完成量得到可信区间
历史速率回答的是“这个团队在一个迭代里通常能完成多少”。取数时只看迭代内实际完成的工作项，迭代结束时未达到完成标准的工作项不计入完成量，即使已经开发了大半。承诺量可以记录，但它是参照项，不能替代完成量参与计算。
取最近3–6个迭代作为样本。样本太短容易受单个迭代波动影响，太长则团队构成和业务复杂度可能已经变化。对明显异常的迭代要单独标注并说明理由，例如迭代中途有长假、核心成员长期缺位、临时插入紧急支持任务，或范围在迭代中被大幅追加。剔除异常迭代后，剩余样本仍应覆盖至少3个迭代，否则区间可信度不足，需要在结论中注明。
表达方式建议用中位数加波动范围，或均值加减一个波动幅度，形成“下限—上限”的区间。中位数对个别偏高或偏低的迭代不敏感，适合样本较少时使用；均值便于和可用人天做比例换算。两种方式都要求估算单位统一：全部用故事点，或全部用人天，跨迭代保持同一口径。中途更换单位会让历史数据失去可比性，需要重新积累基线。
| 迭代编号 | 承诺量 | 完成量 | 异常说明 |
|---|---|---|---|
| 迭代-4 | 42 | 38 | 无 |
| 迭代-3 | 45 | 40 | 无 |
| 迭代-2 | 44 | 22 | 两名核心成员请假两周，剔除 |
| 迭代-1 | 40 | 36 | 无 |
| 当前迭代前 | — | — | 有效样本3个，完成量38、40、36 |
上表有效样本的中位数为38，波动范围36–40，速率区间可记为36–40点。这个区间就是后续容量估算的起点，而不是直接拿40点去承诺。
折算成员可用性：把人员情况换成可用人天
速率反映的是团队在“正常投入”下的产出，本迭代的实际投入需要单独折算。按成员逐一列出本迭代可用天数：用迭代工作日总数减去请假、调休、培训、支持值班、面试等已确定的占用。部分投入成员按实际投入比例折算，例如一半时间投入本迭代的成员，10个工作日折算为5个可用人天。
新人需要按上手程度打折。常见做法是第一个迭代按50%–70%折算，第二个迭代逐步接近全职，具体比例由带教人根据任务独立完成情况判断，并写入假设。打折不是低估新人，而是承认带教、返工和评审会占用团队时间。
可用人天要与速率单位对齐。如果速率用故事点，需要说明换算假设，例如“上季度平均每个故事点约消耗0.6人天”，并注明该比例来自历史工时记录而非精确换算。如果速率本身用人天，可直接比较团队可用投入总量与速率区间，偏差更直观。无论哪种口径，换算假设都要写下来，供迭代后校验。
| 成员 | 角色 | 可用天数 | 折算系数 | 可用投入（人天） |
|---|---|---|---|---|
| 成员A | 后端 | 10 | 1.0 | 10 |
| 成员B | 后端 | 8 | 1.0 | 8 |
| 成员C | 前端 | 10 | 1.0 | 10 |
| 成员D | 前端 | 6 | 1.0 | 6 |
| 成员E | 测试 | 10 | 1.0 | 10 |
| 成员F | 测试 | 5 | 0.8 | 4 |
| 成员G | 设计 | 10 | 0.5 | 5 |
| 成员H | 新人开发 | 10 | 0.6 | 6 |
| 成员I | 运维支持 | 10 | 0.4 | 4 |
| 成员J | 产品 | 10 | 0.5 | 5 |
| 合计 | — | — | — | 68 |
汇总后得到团队可用投入总量，同时标注不确定性：哪些占用已确定、哪些可能变化、新人打折比例的依据是什么。这些说明会在迭代中容量变化时派上用场。
扣减外部依赖与风险，得出可承诺容量
速率区间和可用投入给出的是“理论上能做多少”，还需要扣减外部依赖和风险。列出本迭代所有外部依赖：第三方接口联调、安全评审、数据准备、跨团队交付、环境开通等，逐项估算等待时间和团队配合时间，折算成对容量的占用。依赖等待期间团队并非完全空闲，但切换任务和重新进入状态会损失效率，按实际影响扣减比按零计算更稳妥。
风险缓冲比例根据团队历史偏差设定。如果过去几个迭代完成量普遍低于承诺量10%–15%，缓冲可取10%–15%；如果团队刚经历人员变动或技术方案不确定，缓冲应适当提高。缓冲不是固定值，要在估算表中写明依据，迭代后回看是否足够。
容量区间由此形成：下限是可承诺量，上限是可争取量。承诺取区间下沿，意味着团队对下沿负责；上限用于规划时判断是否还有余力承接额外需求，不作为对外承诺。这样既避免承诺过载，也避免把容量压得过低造成浪费——如果实际完成持续接近上限，说明缓冲设置偏保守，下轮可以收窄。
| 项目 | 数值 | 说明 |
|---|---|---|
| 历史速率区间 | 36–40点 | 3个有效迭代的中位数与波动范围 |
| 可用投入折算 | 68人天 | 按成员可用天数与折算系数汇总 |
| 外部依赖扣减 | -4点 | 第三方联调等待与配合约占用 |
| 风险缓冲 | -10% | 依据近3个迭代平均偏差约12% |
| 可承诺容量 | 28–32点 | 下限28点承诺，上限32点争取 |
角色分工与交付物：谁提供数据、谁确认承诺
容量估算不是迭代负责人一个人的计算，数据来源和承诺责任要分开。产品负责人提供待办优先级和范围候选，明确哪些需求是本迭代必须交付的；团队成员提供各自的可用性和技术依赖信息；Scrum Master或迭代负责人组织估算会议、记录假设和计算过程；承诺由团队共同确认，而不是由管理者单方面下达。
| 角色 | 输入 | 动作 | 输出 | 确认时点 |
|---|---|---|---|---|
| 产品负责人 | 待办优先级、范围候选 | 按优先级排列本迭代候选需求 | 范围候选清单 | 估算会议前 |
| 团队成员 | 个人可用天数、技术依赖 | 提交可用性与依赖信息 | 成员可用性折算表 | 估算会议前 |
| Scrum Master/迭代负责人 | 历史速率数据、可用性表 | 组织估算、记录假设与计算 | 容量估算表 | 估算会议中 |
| 团队 | 容量区间、范围候选 | 讨论并确认承诺范围 | 承诺容量与范围 | 迭代计划会议结束 |
在工具层面，ONES敏捷研发管理解决方案覆盖迭代规划、迭代开发、迭代进度跟进和迭代回顾等场景，产品负责人可按优先级把待办需求规划到对应迭代，并在计划会议上与团队评审。迭代执行中，团队通过敏捷看板和燃尽图跟进进度；ONES Project提供任务工时统计和多种报表，可按自定义数据范围和维度查看项目表现。这些记录可以作为下轮速率取数和偏差复盘的来源，具体报表口径以团队实际配置为准。
示例：一个10人团队如何算出本迭代容量
某10人团队准备规划下一个两周迭代。历史数据取最近4个迭代，其中1个迭代因两名核心成员请假两周被剔除，剩余3个迭代完成量分别为38、40、36点，中位数38，区间36–40点。团队估算单位统一为故事点，上季度工时记录显示平均每点约消耗0.6人天，仅作为换算参考。
成员可用性按前表折算，合计68人天。按0.6人天/点粗略换算，约对应113点的理论投入，明显高于历史速率区间，说明历史速率已经包含了协作损耗、评审等待等隐性成本，不能直接用可用人天除以单点工时来推算容量。正确做法是以速率区间为主，用可用投入判断本迭代投入相对正常水平是偏高还是偏低：本迭代有两人部分投入、一名新人，整体投入略低于正常水平，因此速率区间取下沿附近更稳妥。
外部依赖方面，本迭代有一个第三方接口联调，预计等待2个工作日，团队配合约1个工作日，折算扣减4点。风险缓冲按近3个迭代平均偏差12%设置，取10%。计算过程为：速率区间36–40点，扣减依赖4点得32–36点，再扣减10%缓冲，得到可承诺容量约28–32点。团队在计划会议上确认承诺28点，32点作为争取上限，若提前完成再按优先级从待办中补充。
这个例子说明取舍逻辑：承诺取下沿，是因为依赖等待和新人上手都存在不确定性；上限保留，是为了在进展顺利时不浪费容量。承诺范围写入迭代计划，假设和计算过程一并记录。
迭代中与迭代后的调整：偏差记录与复盘
迭代中容量变化需要设定调整触发条件，例如关键成员临时请假超过2天、外部依赖延迟超过预估等待时间、范围被追加超过承诺量10%。触发后由迭代负责人记录变化内容和影响，团队评估是否调整承诺范围，调整决定要同步给产品负责人。记录的目的不是频繁改承诺，而是让偏差有据可查。
未完成工作不默认结转到下个迭代。迭代结束时未完成的工作项要重新评估：需求是否仍然有效、剩余工作量是否变化、优先级是否调整。重新评估后由产品负责人决定放回待办还是进入下个迭代候选，避免把上个迭代的承诺惯性带入新迭代，导致容量被历史包袱占满。
迭代后对比承诺与实际完成，更新速率样本和可用性假设。如果连续两个迭代实际完成接近上限，说明缓冲偏保守；如果持续低于下限，检查依赖估算和人员折算是否过于乐观。偏差原因沉淀为下轮估算的输入。
| 偏差项 | 原因 | 对下轮估算的修正 |
|---|---|---|
| 实际完成低于承诺5点 | 第三方联调等待比预估多3天 | 同类依赖扣减上调，或提前启动联调 |
| 新人任务返工较多 | 上手折算比例偏高 | 新人首迭代折算系数下调 |
| 实际完成接近上限 | 缓冲设置偏保守 | 缓冲比例下调5个百分点 |
完成检查：容量估算是否可用的核对项
估算完成后逐项核对，全部通过才进入承诺环节。任何一项不通过，先补齐再承诺。
| 核对项 | 通过标准 |
|---|---|
| 速率口径与单位 | 只统计迭代内实际完成的工作项，单位跨迭代统一，异常迭代已标注理由 |
| 可用性折算假设 | 按成员列出可用天数与折算系数，新人打折和部分投入比例有书面依据 |
| 外部依赖与缓冲 | 依赖项、等待时间、扣减量和缓冲比例均显式列出，并有依据说明 |
| 承诺规则 | 承诺取区间下沿，上限作为争取量，团队共同确认并记录 |
| 偏差记录 | 迭代中变化有触发条件和记录，未完成工作已重新评估，偏差原因可用于下轮修正 |
五项都满足，本次容量估算即可作为承诺依据；若速率样本不足3个有效迭代，或依赖扣减无法量化，应在承诺时进一步收窄范围，并在迭代后优先补齐数据。
常见问题
历史速率样本不足3个有效迭代时，还能估算容量吗？
可以估算，但结论要标注可信度不足。样本不足时，建议用已有迭代的完成量作为参考，同时结合团队对本迭代范围的判断，把承诺范围进一步收窄。也可以在估算表中注明“速率基线待积累”，并在接下来两三个迭代中优先补齐数据。样本不足时按上限承诺，容易把偶然波动当成稳定产出。
团队同时维护多个产品或穿插支持任务，可用性怎么折算？
按成员在本迭代的实际投入比例折算，而不是按名义人数计算。先列出每个成员在本迭代可投入本团队工作的天数，再扣除支持值班、跨团队配合等已确定的占用。穿插任务频繁时，折算系数要留出切换成本，并在假设中写明依据。迭代后回看实际投入与折算的偏差，逐步校准系数。
承诺取区间下沿，会不会导致团队长期只完成下限、容量被浪费？
下沿是承诺底线，上限是争取空间，两者配合使用。迭代中如果进展顺利，团队按优先级从待办中补充范围，把余力用掉。复盘时若连续两个迭代实际完成接近上限，说明缓冲偏保守，下轮可以收窄区间或提高下沿。承诺取了下沿就长期不动，才是容量浪费的来源。
外部依赖无法量化等待时间时，容量怎么处理？
无法量化的依赖不要按零扣减。可以按依赖对团队工作的影响范围估算一个保守扣减量，并写明这是估计值；同时把该依赖列为迭代风险，指定跟进人，在迭代中按触发条件记录实际等待时间。迭代后用实际数据修正下轮同类依赖的扣减量。依赖影响大到无法估算时，考虑把相关范围移出本迭代承诺。
迭代中范围被追加，承诺容量要不要跟着改？
先判断追加是否超过承诺量的10%这类预设触发条件。触发后由迭代负责人记录追加内容和影响，团队评估是否调整承诺范围，调整决定同步给产品负责人。追加范围通常应替换原有低优先级范围，而不是在承诺量上直接叠加，否则容量估算失去约束作用。迭代后把追加情况纳入偏差记录。
