一个迭代能装多少，直接决定计划能否兑现。装多了，条目顺延、下一轮计划被打乱；装少了，团队空转、交付节奏变慢。合理的承诺量不是估出来的，而是由容量、速度和缓冲换算得出。下面按口径区分、四步测算、排期动作、失真纠偏、效果验证依次展开。
一、三个口径先分清：时间盒、容量与速度
1. 时间盒定节奏，不定工作量
迭代是固定长度的时间盒，长度确定后不因本轮工作多少而延长。《Scrum指南》2020版要求迭代计划会回答三个问题：为什么这次迭代有价值、这次迭代能完成什么、所选工作如何完成；对于为期一个月的迭代，计划会时长上限为8小时。周期属于约束条件，延长周期会降低反馈频率。
2. 容量看未来，速度看过去
容量（capacity）指本轮可投入的有效工作时间，通常折算为可用人天；速度（velocity）指团队过去若干迭代实际完成的量，属于结果统计。两者口径不同，不能相互替代。把速度当作承诺目标容易失真：历史最好的一次被当成常态，后续每个迭代都在追赶一个不稳定的数字。
3. 三者的分工
下表用于在计划会前统一说法。
口径 | 衡量对象 | 主要用途 | 常见误用 |
|---|---|---|---|
时间盒 | 迭代周期长度 | 稳定交付节奏 | 用延长周期解决装不下 |
容量 | 可用有效投入，常用人天 | 判断本轮上限 | 按满勤计算，忽略会议与支持 |
速度 | 历史完成量，常用故事点 | 校准承诺量 | 取最好的一次当常态 |
容量划定上限，速度提供基准，时间盒确定节奏；三者错位，计划会在迭代中途失控。
二、四步算出本轮容量
容量测算按四步推进，每一步都留下可以复算的记录。
1. 按人和按天扣减，得到真实可用人天
名义投入不能直接用团队人数乘以迭代天数，需要逐项扣减：节假日与调休、年假、评审与例会、线上支持与答疑、新人上手期的效率折损。共享角色按投入到本团队的带宽折算，例如同时支撑两个团队的测试或设计人员，不按满编计入。按人数平均折算会高估容量：《DevData2025研发效能基准报告》基于200余家企业、数万名开发者的数据指出，团队中贡献80%代码的成员占比从百人以内团队的39%降至500人以上团队的31%，人数增长与有效产出并不成正比。
2. 用历史数据校准，不用最乐观的一次
取最近3到5个迭代的完成量，剔除异常值后取中间水平作为基准。速度可作为承诺依据的前提是估算基准不变；当团队人员大幅变动、完成定义调整或估算单位重新对标时，需要重新累计两到三个迭代的数据，再把中间水平作为新基准。
3. 预留计划外工作与风险缓冲
线上问题、临时评审、跨部门支持属于常态支出。可行的做法是统计过去几个迭代计划外工作的平均占比，固定为本轮预留；没有历史数据时先设初始值，例如容量的15%左右，再用两三个迭代的数据修正为团队系数。
4. 把容量换算成条目清单
先算出本轮可承诺的量，再回到待办列表自上而下取条目，取到容量边界为止。
下表为换算示例，数字仅用于演示，实际取值应来自团队的历史数据。
环节 | 示例取值 | 说明 |
|---|---|---|
名义投入 | 6人×10天=60人天 | 未扣减的账面值 |
扣除假期与会议 | 剩余48人天 | 按实际日历与例会扣减 |
预留计划外工作 | 预留7人天 | 由历史占比确定 |
实际可用容量 | 41人天 | 本轮可用的投入 |
容量下降时承诺量同步下调，用加班补回会掩盖容量测算的偏差。
三、排期的三个动作
排期落在迭代管理的日常动作里，核心是三件事。
1. 条目拆到1到3天可验证
拆得太粗，迭代过半才发现进度偏差；拆得太细，计划成本高于收益。每个条目要有可观察的完成标志，例如接口联调通过、页面可演示、脚本可复跑。
2. 先定迭代目标，再排条目
目标对应的条目排在队首，不因中途讨论轻易让位。把每个可用人天都填满，等于取消了对变化和风险的余量，这是迭代最容易失守的地方。目标之外的条目是补充项，标注优先级即可。
3. 依赖与外部输入单独标记
跨团队接口、第三方服务、需要产品确认的规则都会卡住迭代。计划会上单独列出并标记风险，带未决依赖的条目不进入本轮承诺。
四、四种失真信号与纠偏
下表用于站会和复盘中快速定位问题。
失真信号 | 可能原因 | 纠偏动作 |
|---|---|---|
迭代过半进度明显落后 | 容量按满勤计算 | 下一轮按真实可用人天重算 |
条目频繁被移出 | 承诺量超出速度区间 | 用中间水平替代最好成绩 |
计划外工作持续挤占 | 未预留缓冲 | 固定预留比例并计入统计 |
结项前集中赶工 | 条目粒度太粗 | 拆到1到3天并明确完成标志 |
四种信号在迭代流程中常常同时出现，纠偏时一次只调整一个变量，便于判断哪处改动有效。
五、验证排期是否成立
1. 目标达成优先于条目数量
迭代结束时先看目标。目标未达成而条目完成率很高，说明排期偏向填满容量，而不是交付价值。
2. 完成与移出分开统计
被移出多说明承诺量偏高；未完成多指向拆分粒度或依赖处理。合并统计会掩盖两类问题的差别。
3. 计划外工作占比稳定
占比持续升高，说明缓冲定得偏低，或团队承担了过多插队任务。这个比例可以借助燃尽图与累积流图长期观察。三个信号连续两到三个迭代稳定，容量测算才算校准完成。
六、常见问题
团队刚组建、没有历史速度，第一个迭代怎么定承诺量？按可用人天取一个保守下限，只承诺一到两个核心目标，第一个迭代的实际结果作为后续基准。
新人多、老手还要带人，容量怎么算？新人在前两个迭代按成长曲线折算投入，老手用于带人的时间计入成本，不按满编计入可交付工作量。
需求拆分后总量变大，是估算出错吗？多数情况是原先低估了联调、测试与验收工作。用同一估算基准重新确认即可，不要按原数字硬压。
迭代中被撤销的需求，要不要把释放的容量立刻补满？撤销即从本轮移出，但不建议中途补入新条目，避免迭代中途扩容影响承诺的稳定性。
文章标题 ：研发项目管理工具的迭代容量与排期方法：一个迭代装多少 ，发布者 ：项目管理研究院
