迭代容量口径要先把“容量”拆成可计量的对象：以团队在单个迭代时间窗内可投入的有效工时或人天为分母基础，以已承诺工作项的工作量为分子参照，同时写明计入范围、折算规则、时间窗和缺失值处理。本文给出一套可复算的方法，包括指标定义、取数口径、计算步骤和解读边界，并说明如何用两到三个历史迭代回算验证。
要点总览（TL;DR）
- 迭代容量口径先拆成四要素：分母（可用投入）、分子（已承诺工作量）、计入与排除范围、折算与缺失值规则，再谈具体数值。
- 分母以“成员可用工作日×每日有效工时×投入比例”为基础，扣除休假、会议与支持类占用；折算系数写明设定依据与生效迭代。
- 分子取本迭代已承诺工作项的估算值，单位必须统一：人天与工时不可混用，故事点与工时不可直接相加。
- 口径确定后用两到三个历史迭代回算，检查分母稳定性与分子可解释性，再固化为书面定义并随复盘校准。
- 容量利用率只反映承诺与可用投入的匹配程度，不直接等于产出效率；不设通用达标线，阈值结合团队历史数据确定。
评估目标：口径要回答哪个问题
迭代容量口径首先服务于承诺可行性判断：这个迭代团队能接多少工作，当前承诺是否超出可用投入。围绕这个目标，口径要支撑三类决策——承诺多少工作量、当前是否超载、下一迭代如何调整投入或范围。产出效率观察是另一类用途，需要不同的指标组合，不宜让同一个容量数字同时承担两种解释任务。
按使用时点，容量口径分为两种。承诺前估算容量，输入是成员可用工作日、投入比例和历史折算系数，输出是可供承诺的容量上限，用于计划会上的取舍。迭代后核算实际投入，输入是实际工时记录和完成情况，输出是实际消耗与承诺的对比，用于复盘。两者共用分母定义和单位，但取数时点不同，混用会让结果失去可比性。
口径一旦确定，应在多个迭代间保持一致才可比较。中途调整成员范围、折算系数或统计截止点，需要记录变更内容和生效迭代，否则前后数据不能直接放在一条趋势线上看。
指标与范围：容量由哪些量构成
迭代容量由分母和分子两部分构成，并需要明确计入与排除边界。分母是团队在迭代时间窗内的可用投入，分子是本迭代已承诺工作项的工作量估算值。两者单位必须统一，否则比值没有意义。
| 指标 | 分子 | 分母 | 单位 | 计入范围 | 排除范围 |
|---|---|---|---|---|---|
| 可用容量 | — | 成员可用工作日×每日有效工时×投入比例，扣除休假与会议占用 | 人天或工时，全文统一一种 | 本迭代承诺范围内的参与角色 | 未参与本迭代承诺的成员 |
| 承诺工作量 | 本迭代已承诺工作项的估算值汇总 | — | 与容量同单位 | 进入本迭代承诺的需求、任务、缺陷修复与支持类工作（按约定） | 未进入承诺的待办、跨迭代延续工作 |
| 容量利用率 | 承诺工作量 | 可用容量 | 百分比 | 同上 | 同上 |
计入范围要逐项写清：哪些角色计入分母，哪些工作项类型计入分子，缺陷修复和线上支持是否算作承诺工作。缺陷与支持类工作如果长期占用投入却不计入分子，容量利用率会系统性偏高，承诺判断随之失真。排除范围同样要写明：未进入本迭代承诺的待办事项、跨迭代延续的工作不计入本迭代分子，避免把“在手上”误当成“本迭代承诺”。
单位统一是硬约束。人天与工时不可混用，故事点与工时不可直接相加。团队若用故事点估算，容量分母也应折算为故事点口径，或明确容量只做工时口径、故事点仅用于相对比较，两者不放进同一个比值。
数据口径：取数来源与折算规则
取数来源分三类：成员可用工作日来自排班与请假记录；会议、评审、支持等占用来自日历或团队约定；工作项估算值来自工作项上的估算字段。三类数据要在同一时间窗内对齐，才能算出可比的分母和分子。
折算系数用于把名义工作日折算为有效投入。常见做法是给每日有效工时设一个比例，再对会议、支持、评审等非直接投入设扣减比例。系数设定要有依据，例如取近几个迭代的实际工时分布，或由团队在计划会上确认。系数表应写明适用角色、生效迭代和设定依据，调整时保留版本记录。
| 折算项 | 取值方式 | 设定依据 | 生效范围 |
|---|---|---|---|
| 每日有效工时 | 名义工时×有效投入比例 | 团队历史工时分布或计划会确认 | 全体计入成员 |
| 会议与评审占用 | 按迭代内固定会议时长扣减 | 迭代日历中的例行会议 | 按角色分别设定 |
| 支持类工作占比 | 按历史支持工时占比预留 | 近几个迭代支持类工作记录 | 承担支持职责的成员 |
时间窗要写明迭代起止日期和统计截止时点。跨时区团队按统一时区折算工作日，跨周末与法定假日按团队日历扣除。统计截止点通常取迭代结束日，承诺前估算则取计划会当日，两个时点的数据不混用。
缺失值处理需要事先约定：未估算的工作项在分子中如何记（补估、按同类均值暂记或单列不计入比值），中途加入或退出成员在分母中按实际在迭代内的天数折算。口径变更时记录版本号与生效迭代，保证回算时能还原当时的规则。
口径落地需要在工作项估算字段、迭代范围和工作量记录上取数。ONES Project 提供工作项估算与工时记录，迭代范围可按迭代组织工作项，燃尽图和自定义报表可用于查看迭代内工作量分布；容量指标本身需要团队按本文口径自行定义和计算，取数粒度以实际配置为准。
计算与评估步骤：从原始数据到可解释结果
以下步骤保证他人能按同样方式重算，每一步都产出可核对的中间结果。
- 确定迭代时间窗与参与成员名单。写明起止日期、统计截止点和计入成员，形成名单快照。
- 计算可用人天。公式为：成员可用工作日×每日有效工时×投入比例，再扣除休假与会议占用。逐人计算后汇总，保留每人明细以便复核。
- 汇总承诺工作项估算值作为分子参照。按计入范围筛选本迭代承诺的工作项，统一单位后求和，未估算项按约定规则处理并单列。
- 计算容量利用率。公式为：已承诺工作量÷可用容量。分母为零时（如全员休假或名单为空），结果记为“不适用”并说明原因，不输出百分比。
- 用两到三个历史迭代回算。按同一口径重算历史数据，检查分母是否稳定、分子是否可解释、利用率波动是否有对应原因。偏差无法解释时，先修正取数或折算规则，再固化口径。
回算通过后，把口径写成书面定义：指标名、分子、分母、单位、计入与排除范围、折算系数表、时间窗、缺失值规则和版本号。之后每个迭代按同一版本计算，复盘时再评估是否需要校准。
例子：一个迭代的容量回算
以下为方法演示，数值均为假设，不作为达标线。假设一个五人团队，迭代长度两周共十个工作日，每人每日有效工时按六小时计，投入比例取百分之八十，迭代内每人有半天休假、合计四小时会议占用。
可用容量计算：每人可用工作日十个，扣除休假半天后为九点五天；九点五天×六小时×百分之八十，再扣除会议占用，逐人汇总后约为二百一十小时，折合约三十五个人天（按每日六小时计）。
承诺工作量汇总：本迭代承诺的需求与任务估算合计约三十八人天，另有缺陷修复约四人天按约定计入分子，合计四十二人天。容量利用率为四十二÷三十五，约百分之一百二十，说明承诺超出可用投入。
回算前两个迭代发现：上一个迭代利用率约百分之一百一十，再上一个约百分之九十五。偏差原因经核对为支持类工作未预留、部分工作项估算偏乐观。团队据此在折算系数中增加支持占比预留，并约定估算超过一定规模的工作项先拆分再承诺。回算的作用是暴露规则问题，而不是给团队排名。
解读与限制：口径能说明什么、不能说明什么
容量利用率反映承诺与可用投入的匹配程度，不直接等于产出效率。利用率高说明承诺接近或超过投入上限，利用率低说明还有承接空间，两者都不能单独作为团队绩效结论，也不能保证产出结果。
估算精度和工作项拆分粒度会显著影响结果可比性。估算偏乐观会让利用率虚高，拆分过粗会让单项偏差放大。跨迭代比较前，应确认估算习惯和拆分标准没有明显变化。
未完成工作应重新评估后决定是否进入下一迭代，不默认自动结转。直接结转会让下一迭代的分子虚增，容量判断失真。阈值不设通用达标线，应结合团队历史数据确定合理区间，并随团队构成与工作类型变化定期校准口径。
常见问题
团队同时用故事点估算和工时记录，容量口径应该选哪一种？
两种单位各自成立，关键是不要放进同一个比值。若容量分母按工时或人天计算，分子也应取同一单位的工作量估算；故事点适合做工作项之间的相对比较和迭代内进度观察，不宜直接与工时容量相除。团队可以保留故事点用于承诺讨论，同时单独维护工时口径的容量计算，并在书面定义中写明两套口径各自的用途，避免复盘时把两个数字混在一起解释。
迭代中途有成员加入或请假，分母要不要重算？
承诺前估算按计划会当日的名单快照计算，中途变化不回溯修改已承诺的容量上限，否则承诺判断失去参照。迭代后核算实际投入时，分母按成员实际在迭代内的天数折算，加入者从加入日起计入，请假按实际缺勤天数扣除。两种口径分别记录，复盘时对照承诺容量与实际投入的差异，就能看出人员变动对迭代的影响程度。
缺陷修复和线上支持长期占用投入，应该计入分子吗？
建议按团队约定明确计入，并在折算系数中同步预留支持类工作的投入比例。如果支持类工作占用投入却不计入分子，容量利用率会系统性偏高，承诺判断随之失真。常见做法是给承担支持职责的成员在分母中预留一定比例，同时把本迭代承诺处理的缺陷修复计入分子，两边口径对齐后再计算比值。约定一旦确定，应在多个迭代间保持一致并记录版本。
回算历史迭代时发现利用率波动很大，先改口径还是先改估算？
先定位波动来源再决定改什么。逐迭代核对分母是否稳定（成员范围、休假与会议扣减是否一致）、分子是否可解释（是否有未估算项、拆分粒度是否变化）。若分母稳定而分子波动来自估算偏乐观或工作项拆分过粗，优先调整估算与拆分规则；若分母本身取数不一致，先修正取数与折算规则。两类问题都排除后，再把口径固化为书面定义，避免用调整口径的方式掩盖估算问题。
容量利用率算出来超过百分之百，说明什么？
说明本迭代承诺的工作量超过了按当前口径计算的可用投入，团队可能面临超载。此时应回到承诺清单，确认是否有工作项可以移出本迭代、是否需要拆分过大的工作项、支持类工作的预留是否充分。利用率超过百分之百本身不构成绩效结论，也不代表一定无法交付，它提示的是承诺与投入之间的缺口，需要在计划阶段处理，而不是留到迭代结束后解释。
