迭代容量和团队速率（velocity）都用来描述“一个迭代能做多少工作”，但时间位置和用途不同：容量是迭代开始前按成员可用时间估算出的可投入上限，回答“这个迭代能接多少工作”；速率是若干已完成迭代实际交付量的统计值，回答“团队过去每个迭代通常能完成多少”。理解这一区别，才能避免把历史统计直接当成计划承诺。
要点总览（TL;DR）
- 迭代容量是迭代开始前按成员可用时间、投入比例和事项拆分估算出的可投入上限，回答“这个迭代能接多少工作”。
- 团队速率（velocity）是若干已完成迭代实际交付量的统计值，回答“团队过去每个迭代通常能完成多少”。
- 容量用于排入工作并留出余量，速率用于参考长期交付水平和回顾偏差，两者使用同一估算单位才有可比性。
- 把速率直接当成下个迭代的容量上限，或用单次迭代数据判断趋势，是两类常见误用。
- 衔接的关键是迭代前按容量定范围、过程中记录状态与工时、结束后按统一口径统计速率并对比回顾。
迭代容量与团队速率分别是什么
迭代容量（Iteration Capacity）指团队在某个具体迭代内可投入的工作量上限。它由参与该迭代的成员、各成员的可用天数、每日有效工时、投入比例以及事项的估算粒度共同决定，是一个面向未来的计划约束。容量回答的是“在现有人员和时间的条件下，这个迭代最多能承接多少工作”。
团队速率（Velocity）指团队在若干已完成迭代中，每个迭代实际交付工作量的统计值。它以迭代结束时真正完成的事项为准，按统一估算单位汇总，反映团队在一段时间内稳定表现出的交付水平。速率回答的是“团队过去每个迭代通常能完成多少”。
一句话区分：容量是迭代开始前的可投入上限，速率是迭代结束后的历史交付统计。前者用于排入工作，后者用于参考趋势。两者使用相同的估算单位时才有可比性，但即使单位一致，容量也不等于速率，因为容量是计划值，速率是实际值。
两者的边界：各自包括和不包括什么
把容量和速率的范围划清，能减少实际使用中的口径混用。容量关注“能投入多少”，速率关注“已完成多少”，两者都不承担绩效评价的职能。
迭代容量包括与不包括
- 包括：成员在该迭代的可用时间、投入比例（如兼职成员按比例折算）、事项拆分到可估算的粒度、计划内的请假与公共假期。
- 不包括：历史交付统计、成员个人绩效评价、未拆分清楚的大型需求。容量是团队层面的投入上限，不用于比较成员之间的产出高低。
团队速率包括与不包括
- 包括：已完成事项的统计口径（什么状态算完成）、统一的估算单位、按迭代汇总的统计周期。
- 不包括：对下一个迭代的承诺值。速率是历史参考，不能直接写成下个迭代必须达成的目标。
还需要注意未完成工作的处理：迭代结束时未完成的事项需要重新评估，根据剩余工作量和优先级决定是否放回待办列表或排入后续迭代，不默认自动结转到下一个迭代的容量中。自动结转会让下一个迭代的容量被高估，也会让速率的统计口径变得模糊。
容量怎么算、速率怎么统计：机制与组成
容量和速率的数值来源不同，计算方式也不同。理解机制，才能判断一个数字是否可信。
容量的估算要素
容量的基本算法是按人汇总可投入时间，再折算为可承接的工作量。常见要素包括：
- 人数：本迭代实际参与的成员，不含全程请假或未投入的成员。
- 可用天数：迭代周期内扣除假期、培训、会议等占用后的工作日。
- 每日有效工时：用于开发、测试、设计等交付活动的时间，需扣除日常沟通与支持性事务。
- 投入比例：兼职参与某项目的成员按实际投入比例折算。
- 事项估算单位：故事点、人天或其他团队约定的单位，需与速率统计保持一致。
汇总时通常先算出团队总可投入工时，再结合历史经验折算为可承接的事项数量或故事点。常见调整项包括：迭代内计划外的支持请求、新成员上手带来的效率折损、依赖外部团队导致的等待时间。这些调整应在计划阶段明确写出，而不是等到迭代中途再临时压缩范围。
速率的统计口径
速率的统计遵循三条基本规则：以已完成事项为准，只统计迭代结束时达到完成标准的事项；统一估算单位，同一团队在不同迭代中使用同一种单位；按迭代汇总，每个迭代得到一个数值，连续多个迭代的数值才构成有参考意义的序列。
单个迭代的速率容易受需求规模、人员变动、外部依赖等偶然因素影响，通常需要积累若干迭代的数据，才能看出相对稳定的区间。估算单位不一致会同时影响容量和速率：如果这个迭代用故事点、下个迭代改用人天，容量估算和速率统计都会失去可比性，历史数据也无法用于参考。
容量和速率容易混淆的相邻概念
容量和速率常与承诺、负载、吞吐量等术语一起出现，混用会导致计划与回顾的结论失真。下表按同一口径对照几个相邻概念。
| 概念 | 时间位置 | 数据性质 | 主要用途 |
|---|---|---|---|
| 迭代容量 | 迭代开始前 | 计划估算值 | 确定本迭代可承接的工作范围 |
| 团队速率 | 迭代结束后 | 历史统计值 | 参考团队长期交付水平 |
| 承诺值 | 迭代开始前 | 团队对外或对内的约定 | 明确本迭代必须达成的范围 |
| 人员负载 | 任意时刻 | 当前分配状态 | 查看成员手头工作的多少 |
| 吞吐量 | 一段时间内 | 完成事项的数量统计 | 观察单位时间内完成的事项数 |
| 周期时间 | 单个事项 | 从开始到完成的时间 | 分析单项工作的流转效率 |
容量与速率的关系是计划上限与历史实际的关系：容量决定这个迭代能排入多少，速率提供过去实际完成了多少作为参照。速率与承诺的区别在于，速率是统计结果，承诺是团队在计划会议上基于容量和速率共同做出的约定，承诺值可以低于容量上限，以留出应对变化的余量。
容量与人员负载、资源利用率的区别在于视角：容量是迭代层面的可投入总量，负载是成员当前被分配的工作状态，资源利用率衡量的是投入时间被使用的比例。速率与吞吐量、周期时间的区别在于统计对象：速率按迭代汇总工作量，吞吐量统计完成事项的数量，周期时间关注单个事项的流转时长。同一团队内保持估算单位一致，是这些概念能够互相参照的前提。
分别适合回答什么问题：具体例子
两个概念各自回答一类问题，混用会让计划失去依据。下面按问题类型分别列出，并用一个完整迭代说明配合方式。
容量适合回答的问题
- 这个迭代团队能接多少需求？在人员和时间确定后，可承接的范围有多大？
- 两名成员请假一周，本迭代的范围需要压缩多少？
- 新成员加入后，投入比例按多少折算，容量如何调整？
- 计划外的支持请求占用了时间，是否需要把部分需求移出本迭代？
速率适合回答的问题
- 团队最近几个迭代的交付水平大致在什么区间？
- 下个迭代在人员不变的情况下，大致能完成多少工作？
- 连续几个迭代速率下降，可能与哪些因素有关？
- 回顾时，本迭代的实际完成与计划容量差了多少？
一个完整迭代的示例
假设某团队在迭代计划前先估算容量：五名成员，迭代周期两周，扣除假期和会议后每人可用八天，按投入比例折算后得到团队总可投入工时，再换算为可承接的故事点范围。团队据此从待办列表中排入需求，并留出一定余量应对计划外事项。迭代过程中，成员拆解任务并更新状态。迭代结束后，只统计达到完成标准的事项，按同一估算单位汇总，得到本迭代的速率。回顾时把实际完成与计划容量对比，分析偏差来自估算偏大、计划外中断还是依赖等待，并把结论用于下一个迭代的容量估算。
常见误解有两类：一是把速率直接当成容量上限，认为上个迭代完成了多少，这个迭代就必须排入多少，忽略了人员变化和计划外事项；二是用单次迭代的数据判断趋势，一个迭代的波动不足以说明交付水平变化，需要结合多个迭代观察。容量偏差通常通过调整投入比例、压缩范围或重新拆分事项来处理；速率波动则先排查口径是否一致、完成标准是否变化，再分析人员、需求和外部依赖的影响。
在迭代运行中如何把两者衔接起来
容量和速率不是两套独立的数字，而是一条从计划到回顾的流程中的两个节点。衔接的关键是保持记录口径一致，让每个迭代的容量估算和速率统计能够互相对照。
迭代开始前，团队按容量确定可承接范围：明确参与成员、可用时间和投入比例，把需求拆分到可估算的粒度，据此排入工作并留出余量。迭代过程中，成员拆解任务、更新事项状态，记录实际投入的工时和完成情况，这些记录是后续统计速率的基础。迭代结束后，按统一口径统计速率，只计入达到完成标准的事项。回顾时，把实际完成与计划容量对比，识别偏差原因：是容量估算偏高、计划外中断过多，还是事项拆分不够细导致估算失真。
在 ONES 中，这一过程可以依托迭代工作项、任务工时统计和状态记录来承载。产品负责人可按需求优先级把待办列表中的需求规划至对应迭代，并在迭代计划会议上与团队共同评审；迭代过程中，团队成员围绕迭代需求拆解任务，通过敏捷看板管理任务状态；迭代完成并发布后，可通过燃尽图、工时日志等数据报表复盘进度、质量和成本偏差。ONES Project 提供任务工时统计与看板、燃尽图等工具，便于在迭代运行中持续记录进度。需要说明的是，容量估算和速率统计的具体口径仍需团队自行约定，工具承载的是记录与汇总环节。
常见问题
迭代容量估算出来以后，还需要再参考速率吗？
需要，但两者的角色不同。容量给出的是本迭代的可投入上限，速率提供的是过去几个迭代实际完成了多少的参照。计划时可以先按容量算出可承接范围，再对照近期速率判断这个范围是否偏乐观：如果容量算出的范围明显高于团队长期实际完成水平，就要检查估算粒度、投入比例或计划外事项是否被低估。
速率不直接决定容量，它帮助团队校准容量估算的合理性。人员、需求类型或完成标准发生明显变化时，历史速率的参考价值会下降，应以当期容量估算为主。
团队刚组建或刚换估算单位，速率还没有积累，怎么排迭代？
这种情况下以容量为主要依据，把首个迭代的范围控制得保守一些，并留出应对不确定性的余量。速率需要连续多个迭代的数据才具备参考意义，前几个迭代的数值更多用于建立基线，不宜直接当作承诺依据。
同时要尽早固定估算单位，避免中途从故事点改为人天或反之。单位一旦切换，之前积累的速率数据与新的容量估算就失去可比性，需要重新开始积累。
迭代结束时未完成的事项，应该计入速率吗？
不计入。速率的统计口径以迭代结束时达到完成标准的事项为准，未完成事项不纳入本迭代的交付量。这些事项需要重新评估剩余工作量和优先级，再决定是否放回待办列表或排入后续迭代，不默认自动结转到下一个迭代的容量中。
如果直接把未完成事项带入下个迭代并计入容量，下个迭代的可投入上限会被高估，速率的历史序列也会因为口径混杂而失真。
容量和速率出现明显偏差时，先查什么？
先查口径，再查原因。确认两个迭代的估算单位是否一致、完成标准是否变化、统计周期是否相同，口径不一致时数值本身就没有可比性。
口径一致的前提下，再分析偏差来源：容量估算是否偏大，计划外支持请求是否占用了较多时间，是否存在依赖外部团队的等待，事项拆分是否过粗导致估算失真。容量偏差通常通过调整投入比例、压缩范围或重新拆分事项来处理；速率波动则要结合多个迭代观察，单个迭代的起伏不足以说明交付水平变化。
在 ONES 中记录迭代运行，容量和速率的口径需要自己定吗？
需要。ONES 可以承载迭代工作项、任务工时统计、看板与燃尽图等记录和汇总环节，产品负责人可把待办列表中的需求规划至对应迭代，团队成员在迭代中拆解任务并更新状态，迭代完成后通过报表复盘进度与偏差。
容量估算采用什么单位、哪些状态算完成、速率按什么周期汇总，这些口径仍需团队自行约定并保持一致。工具负责记录与呈现，口径的一致性决定了这些数据能否用于跨迭代对比。
