迭代容量测算表以“成员×迭代”为基本行，核心列包括成员、可用工作日、每日有效工时、专注系数、计划占用工时和个人容量，再用汇总行算出团队总容量与负载率。公式保持简单可核对：个人容量＝可用工作日×每日有效工时×专注系数−计划占用工时；团队容量＝各成员个人容量之和；负载率＝已承诺工作量÷团队总容量。下面给出一张可直接复制到表格工具的空白模板，并逐列说明口径、必填取舍、填写示例与后续维护方法。
要点总览（TL;DR）
- 测算表以“成员×迭代”为基本行，成员明细区放个人数据，团队汇总区放总容量、已承诺工作量、负载率和剩余容量。
- 核心公式：个人容量＝可用工作日×每日有效工时×专注系数−计划占用工时；团队容量＝各成员个人容量之和；负载率＝已承诺工作量÷团队总容量。
- 必填列是支撑公式成立的最小集：成员、可用工作日、每日有效工时、专注系数、计划占用工时、个人容量及汇总区四项；角色、备注、剩余容量、按工作类型拆分等列可按团队情况增补。
- 专注系数和每日有效工时是团队经验参数，应依据本团队历史数据设定，并在迭代回顾中校准，直接套用外部固定值容易让测算失真。
- 每个迭代结束回填实际投入与完成量，对比计划值调整参数；未完成工作逐项重新评估优先级和工作量，不默认自动结转。
可复制空白测算表
这张表分两个区域：上方是成员明细区，一行对应一位成员；下方是团队汇总区，一行对应一个迭代。复制到 Excel、在线表格或文档表格中即可填写，公式列已标注填写位置。示例中的“迭代名称”一栏先留空，填表时统一填写同一个迭代。
成员明细区
| 行号 | 成员 | 角色 | 可用工作日 | 每日有效工时 | 专注系数 | 计划占用工时 | 个人容量（公式列） | 备注 |
|---|---|---|---|---|---|---|---|---|
| 1 | ＝D2*E2*F2−G2 | |||||||
| 2 | ＝D3*E3*F3−G3 | |||||||
| 3 | ＝D4*E4*F4−G4 | |||||||
| 4 | ＝D5*E5*F5−G5 | |||||||
| 5 | ＝D6*E6*F6−G6 |
团队汇总区
| 项目 | 填写位置 | 公式或取值 |
|---|---|---|
| 迭代名称 | B10 | 手工填写 |
| 团队总容量（人时） | B11 | ＝SUM(H2:H6) |
| 已承诺工作量（人时） | B12 | 手工填写，取自迭代待办的工作量估算合计 |
| 负载率 | B13 | ＝B12/B11 |
| 剩余容量（人时） | B14 | ＝B11−B12 |
行号按五人小组示例编排，成员增减时同步扩展明细区行数，并把汇总区的 SUM 范围改为覆盖全部成员行。公式列只保留一个，避免同一数值在多处手工填写造成对不上。
每一列的含义与计算口径
测算表能否用得住，取决于每列取值是否来自同一口径。下表逐列说明含义、取值来源和计算方式，与上一节模板的列名一一对应。
| 列名 | 含义 | 取值来源 | 计算方式 |
|---|---|---|---|
| 成员 | 参与本迭代交付的人员 | 团队名单，按实际投入迭代的人填写 | 直接填写 |
| 角色 | 成员在迭代中的主要职责 | 团队分工 | 直接填写，用于核对投入结构 |
| 可用工作日 | 迭代周期内该成员实际可出勤的工作日 | 迭代日历扣除法定假日、个人休假 | 迭代总工作日−缺勤日 |
| 每日有效工时 | 一个工作日中可投入迭代交付的工时 | 团队历史作息与会议安排 | 按团队经验设定，通常低于名义工时 |
| 专注系数 | 扣除打断、协作、临时事务后真正用于交付的比例 | 团队历史数据或回顾结论 | 0到1之间的小数，如0.7表示七成时间用于交付 |
| 计划占用工时 | 迭代内已确定不用于交付的工时 | 休假、固定会议、值班支持、培训等安排 | 逐项累加为小时数 |
| 个人容量 | 该成员本迭代可承接的工作量 | 由前几列计算 | 可用工作日×每日有效工时×专注系数−计划占用工时 |
| 团队总容量 | 全团队可承接的工作量合计 | 明细区个人容量 | 各成员个人容量之和 |
| 已承诺工作量 | 本迭代计划完成的工作量估算合计 | 迭代待办的工作量估算 | 逐项累加，单位与容量保持一致 |
| 负载率 | 承诺工作量占团队容量的比例 | 汇总区两行数据 | 已承诺工作量÷团队总容量 |
| 剩余容量 | 承诺后仍可调配的余量 | 汇总区两行数据 | 团队总容量−已承诺工作量 |
几个口径需要单独说明。可用工作日按迭代实际日历计算，遇到跨节假日或成员集中休假的迭代，这一列会明显低于常规值，属于正常结果。每日有效工时和专注系数都是团队经验参数，应依据本团队历史数据设定，在迭代回顾中校准，直接套用外部固定值容易让测算失真。计划占用工时只统计已确定发生的非交付安排，临时插入的支持任务在迭代中记录，作为下一轮调整参数的依据。
个人容量与团队容量是加总关系，团队容量不单独估算，避免两套口径互相矛盾。负载率超过1表示承诺量超出容量，需要削减范围或调整人员；低于1则剩余容量为正，可留作缓冲或承接插入需求。剩余容量为负数时，其绝对值就是超载量，可直接用于和团队沟通取舍。
必填列与选填列怎么区分
判断一列是否必填，标准是缺了它公式能否成立。支撑容量计算的最小列集是：成员、可用工作日、每日有效工时、专注系数、计划占用工时、个人容量，加上汇总区的团队总容量、已承诺工作量、负载率。这几列缺失时，个人容量或负载率无法算出，测算表就失去作用。
必填列清单
- 成员：明细区每行必须对应一位实际投入迭代的人。
- 可用工作日：决定个人容量的时间基数。
- 每日有效工时：把工作日换算为可交付工时。
- 专注系数：反映真实交付比例，缺省按1处理会高估容量。
- 计划占用工时：没有这一列，休假和会议占用会被漏算。
- 个人容量、团队总容量、已承诺工作量、负载率：公式列，必须保留。
选填列清单
- 角色：用于检查投入结构是否合理，小团队可省略。
- 备注：记录特殊安排，如某成员半程加入。
- 剩余容量：负载率已能反映余量，单独列出便于沟通。
- 按工作类型拆分的容量列，如需求、缺陷、技术支持各占多少：适合多线并行的团队。
- 历史负载率对照列：适合已积累多个迭代数据的团队做趋势比较。
选填列缺失时按默认方式处理：角色缺失不影响计算，只在汇总时少一个结构视角；备注缺失时把特殊安排写进计划占用工时的说明；剩余容量缺失时用团队总容量减已承诺工作量临时算出；拆分列缺失时先按总量测算，等团队稳定后再细化。选填列的作用是提高解释力，不改变核心公式。
一份填好的测算示例
以下是一个五人小组、两周迭代的填写示例，数据为演示情景，用于说明公式如何落地，不代表任何真实团队的水平。
| 成员 | 角色 | 可用工作日 | 每日有效工时 | 专注系数 | 计划占用工时 | 个人容量（人时） |
|---|---|---|---|---|---|---|
| 甲 | 后端 | 10 | 6 | 0.8 | 4 | 44 |
| 乙 | 后端 | 8 | 6 | 0.8 | 0 | 38.4 |
| 丙 | 前端 | 10 | 6 | 0.7 | 6 | 36 |
| 丁 | 测试 | 10 | 6 | 0.75 | 2 | 43 |
| 戊 | 产品 | 6 | 5 | 0.6 | 3 | 15 |
以甲为例：10×6×0.8−4＝44人时。乙休假两天，可用工作日为8，计算得38.4人时。戊半程参与迭代，可用工作日只有6，每日有效工时按5计，专注系数0.6，再扣3小时会议，得15人时。逐行算完后，团队总容量为44＋38.4＋36＋43＋15＝176.4人时。
| 项目 | 数值 |
|---|---|
| 团队总容量 | 176.4人时 |
| 已承诺工作量 | 160人时 |
| 负载率 | 约0.91 |
| 剩余容量 | 16.4人时 |
负载率约0.91，说明承诺量略低于团队容量，留有约一成缓冲，适合应对评审返工或临时支持。若已承诺工作量填到190人时，负载率约1.08，剩余容量为负，团队需要在计划会上删减范围或协调人手，而不是靠加班消化。示例中测试与产品的容量明显低于开发，是因为可用工作日和专注系数不同，这类差异正是测算表要暴露的信息。
模板的调整与迭代后维护
模板建好后需要随团队变化调整，并在每个迭代结束时回填实际值，才能让下一轮测算更准。调整和维护可以按下面的清单执行。
按团队情况调整列
- 团队人数超过十人时，按小组拆分明细区，每组一个汇总行，再增加一行全团队合计。
- 存在多工作类型并行时，在明细区增加需求、缺陷、支持三类工时列，个人容量仍按总量计算。
- 有成员中途加入或退出时，在备注列注明参与区间，可用工作日按实际区间折算。
- 跨时区或远程协作的团队，可在每日有效工时旁增加协作时段说明，避免口径混淆。
每迭代开始前的填写时点
- 在迭代计划会前完成明细区填写，由各成员确认自己的可用工作日和计划占用。
- 计划会上对照团队总容量评审待办，确定已承诺工作量后填入汇总区，当场算出负载率。
- 负载率明显偏离团队惯常区间时，当场调整范围，不把问题留到迭代中段。
迭代结束后的回填与复盘
- 回填每位成员的实际投入工时和实际完成工作量，与计划值并列保留。
- 对比个人容量的计划值与实际值，偏差持续偏大的成员，下一轮调整其专注系数或每日有效工时。
- 统计计划占用工时的实际发生额，把反复出现的会议、支持类占用固化进下一轮预估。
- 在迭代回顾中讨论负载率与实际交付的关系，形成下一迭代的参数取值。
未完成工作的处理
- 迭代结束时逐项列出未完成工作，重新评估优先级和工作量，不默认自动结转到下一迭代。
- 确认仍需做的工作进入下一迭代待办，并计入下一轮的已承诺工作量。
- 因容量估算偏差导致的未完成，把偏差原因写进回顾记录，作为调整参数的依据。
测算表需要和迭代中的工作项、工时记录对应起来，回填才有数据来源。在 ONES 中，产品负责人可按优先级把待办需求规划到对应迭代，并在迭代计划会上与团队评审；迭代过程中成员拆解任务、通过敏捷看板管理状态，工时日志与燃尽图为回顾提供进度和成本数据。迭代结束后，团队可用这些报表复盘偏差，并用 ONES Wiki 把参数调整结论沉淀为团队知识，让下一轮容量测算沿用同一口径。
常见问题
团队没有历史数据，专注系数和每日有效工时怎么定初始值？
可以先按保守估计起步：每日有效工时取名义工时的一半到三分之二，专注系数取0.6到0.8之间，然后在头两三个迭代中回填实际投入工时，对比计划值逐步修正。关键是同一团队在连续迭代中使用同一口径，让偏差可比较，而不是一开始就追求精确。若团队会议和支持事务较多，初始值应更低，避免首轮测算高估容量。
迭代中途有成员请假或临时加入，测算表怎么更新？
在成员明细区修改该成员的可用工作日和计划占用工时，个人容量与团队总容量会随之重算；中途加入的成员新增一行，并把汇总区的求和范围扩展到新行。更新后重新核对已承诺工作量与新的团队总容量，负载率明显超出惯常区间时，在迭代中段就与团队沟通范围取舍，把调整记录在备注列，作为回顾时的依据。
已承诺工作量和容量的单位必须一致吗？用故事点还是人时？
必须一致。模板默认用人时，因为可用工作日、每日有效工时和计划占用工时都以小时计量，直接相除得到负载率。若团队习惯用故事点估算待办，可以保留人时容量作为参照，另设一列故事点承诺量，但负载率应改用同一单位计算，避免人时与故事点混算。两种单位并存时，在表头注明各自用途。
负载率算出来超过1，除了删减范围还有别的处理方式吗？
可以先核对参数是否偏保守，例如专注系数是否设得过低、计划占用工时是否重复计入；参数确认合理后，再考虑调整迭代范围、协调其他成员分担、把部分工作移到下一迭代，或与相关方沟通交付时间。负载率长期高于1说明团队持续超载，应在回顾中讨论承诺机制和需求进入节奏，而不是靠加班消化。
测算表需要和工具里的迭代数据对应吗？
对应起来回填才有可靠来源。测算表本身负责计划侧估算，迭代中的工作项状态和工时记录提供实际值。在 ONES 中，产品负责人可按优先级把待办需求规划到对应迭代，并在迭代计划会上与团队评审；迭代过程中成员拆解任务、通过敏捷看板管理状态，工时日志与燃尽图为回顾提供进度和成本数据；迭代结束后可用这些报表复盘偏差，并用 ONES Wiki 把参数调整结论沉淀为团队知识。
