迭代容量计算的核心，是把团队在一个迭代内真实可投入的人力与时间，折算成可以承诺的工作量。常用口径为“迭代容量＝Σ（成员可用天数×每日有效工时×专注系数）÷单位任务平均耗时”。计算前要先确定单位、统计时间窗和成员可用性，扣除休假、会议、支持等非迭代投入；结果用于Sprint规划与范围调整，是承诺上限，需要结合历史完成率校准，并说明分母为零、单位不可比等限制。
要点总览（TL;DR）
- 迭代容量的主公式是：容量＝Σ（成员可用天数×每日有效工时×专注系数）÷单位任务平均耗时，分子是净可用工时，分母是完成一个单位任务的平均耗时。
- 计算前先固定四件事：统计对象与角色、容量单位（人天、工时或故事点，全团队统一一种）、迭代时间窗与工作日口径、纳入与排除项（休假、会议、值班支持、跨团队支援）。
- 数据来自考勤排班与团队确认的可用性、近三到六个迭代的完成记录，以及有记录依据的专注系数假设；缺失值和异常值要按预设规则替代或剔除并留痕。
- 容量是承诺上限而非必须填满的指标：结果向下取整并留出缓冲，缓冲只在专注系数或结果扣减中选一种方式，避免重复扣减。
- 用多个迭代的完成率趋势校准参数，结合完成率、缺陷情况、交付周期等指标综合评估；未完成工作进入新迭代需重新评估，不默认结转。
迭代容量要回答什么评估问题
容量评估要回答的问题是：这个团队在当前迭代里，能够稳定承诺多少工作。它把“有哪些人、能投入多少时间、做一件事大概要多久”这三类信息放在一起，得出一个可承诺的工作量范围，供Sprint规划时确定范围。
容量、速率和承诺量是三个不同概念，混用会让规划失真。容量是从投入侧推算出的理论上限；速率是团队在过去若干迭代中实际完成的工作量；承诺量是团队在规划会上最终接下、愿意为之负责的范围。合理的顺序是先算容量，再参考历史速率，最后确定承诺量，承诺量通常不超过容量，并留出缓冲。
容量结果主要用在三个场景。第一是Sprint规划，用容量判断候选工作项总量是否超出团队可承受范围，超出时按优先级裁剪。第二是范围调整，迭代中途出现人员变动、临时支持任务或需求插入时，用容量重新判断剩余工作是否可行。第三是未完成工作重新评估，上个迭代未完成的事项进入新迭代前，要按新迭代的容量重新排优先级和估算，不能默认全部结转。
容量结果的使用边界需要提前说清：它是规划工具，不是绩效考核指标。容量算得准，说明团队对投入和耗时的判断趋于稳定；容量与实际完成之间的差距，反映的是估算偏差、外部干扰或范围变化，不能直接等同于成员努力程度。把容量当作考核目标，容易导致虚报可用时间或压低估算，反而破坏数据的可信度。
容量指标与统计范围怎么定
计算容量前，先写清楚一张指标定义表，把对象、单位、时间窗和纳入排除四件事固定下来。口径一旦确定，同一团队在多个迭代之间应保持一致，否则容量数据无法横向比较。
| 定义项 | 需要明确的内容 | 常见选择 |
|---|---|---|
| 统计对象 | 哪些成员、哪些角色计入容量 | 直接参与交付的开发、测试、设计等角色；管理者按实际投入比例计入 |
| 单位 | 容量以什么单位表达 | 人天、工时或故事点，全团队统一一种 |
| 时间窗 | 迭代起止日期与工作日口径 | 按迭代日历扣除周末与法定假日 |
| 纳入项 | 哪些投入计入可用时间 | 正常工作日内的有效交付时间 |
| 排除项 | 哪些投入不计入或需扣减 | 休假、培训、会议、值班支持、跨团队支援 |
单位选择决定后续公式的形态。以人天或工时为单位时，容量直接表达为时间总量，适合与任务估算的耗时对齐；以故事点为单位时，需要先有稳定的故事点与耗时对应关系，再通过单位任务平均耗时把时间折算成点数。两种单位不能在同一张容量表里混用，也不能把人天容量直接与故事点估算的工作项比较。
纳入与排除范围要按角色和场景分别约定。休假、培训、法定假日属于整段不可用时间，直接从可用天数中扣除；会议、值班支持、跨团队支援属于持续性占用，按比例折算成每日可用工时的扣减。跨团队支援如果占用半天以上，建议单独列为排除项，避免在专注系数里重复扣减。
数据口径与证据从哪里取
容量计算需要三类数据：成员可用性、历史完成情况和专注系数等假设值。每类数据都要有明确来源和记录方式，保证下个迭代可以复算、可以追溯。
成员可用性数据来自考勤记录、排班表或团队在规划会前的书面确认。字段至少包括成员、角色、迭代内可用天数、每日计划投入工时、已批准的休假与外部支援安排。考勤与排班能提供客观基础，团队确认用于补充排班未覆盖的临时安排，两者结合可以减少遗漏。
历史完成数据来自上个或近几个迭代的完成记录，字段包括完成的工作项、各项的实际耗时或故事点、迭代起止日期。计算单位任务平均耗时时，建议取近三到六个迭代的完成项，剔除明显异常的大项或返工项，避免单次特殊情况拉偏平均值。
专注系数是假设值，来源要写清楚。常见做法是团队根据历史观察约定一个比例，例如每日有效工时中用于迭代内交付的比例，并在每个迭代结束后用实际数据回看是否合理。假设值要连同取值依据、约定日期和约定人一起记录，便于后续校准时有据可查。
缺失值与异常值需要预设处理规则。成员可用天数缺失时，按排班或默认工作日补齐并标注“估算”；历史耗时缺失时，用同类任务的平均值替代并标注替代来源；出现明显偏离的异常值，先核实是否为记录错误，确认属实的单独说明，不直接纳入平均值。所有替代和剔除都要在容量记录中留痕，避免口径悄悄变化。
当团队使用工作项工具管理迭代时，成员可用性、工作项工时和历史完成记录可以集中在一处维护。例如在ONES中，迭代下的工作项可记录预估工时与实际工时，迭代结束后按迭代筛选即可导出完成项与耗时，作为单位任务平均耗时和历史完成率的取数来源；成员休假与投入比例也可以在规划阶段由团队统一确认后记录，减少每次手工汇总的重复工作。
迭代容量的计算步骤与公式
容量计算的主公式为：迭代容量＝Σ（成员可用天数×每日有效工时×专注系数）÷单位任务平均耗时。分子是团队在迭代内可投入的有效工时总量，分母是完成一个单位任务平均需要的时间，两者相除得到以“任务单位”表达的容量。
按以下步骤计算，每一步都保留中间结果，便于复核：
- 确定单位。选定人天、工时或故事点中的一种，并确认分母与该单位一致。
- 汇总可用工时。逐成员计算“可用天数×每日有效工时”，再求和得到团队毛可用工时。
- 乘专注系数。用毛可用工时乘以团队约定的专注系数，得到净可用工时，即分子。
- 确定分母。用历史完成数据计算单位任务平均耗时，即总耗时除以完成任务数。
- 相除折算。净可用工时除以单位任务平均耗时，得到容量结果。
- 取整并设缓冲。结果向下取整为可承诺的整数单位，再按团队约定留出缓冲，缓冲部分不纳入承诺范围。
分母为零或单位不可比时要单独处理。分母为零通常意味着历史完成数据不足或单位任务定义过细，此时不强行计算，改为按人天直接表达容量，或先积累一个迭代的完成数据再折算。单位不可比指容量单位与工作项估算单位不一致，例如容量以人天表达而工作项以故事点估算，这时要么统一换算口径，要么在规划时只用人天容量做总量约束，不逐项对应。
结果取整建议向下取整，避免把容量算得偏乐观。缓冲的设置方式有两种：一种是在专注系数中已经包含缓冲，另一种是在容量结果上再扣减固定比例。两种方式选一种即可，不要重复扣减，否则容量会被系统性低估。
一个五人团队的计算示例
以下为演示情景，数据为假设值，用于说明计算过程，不代表任何真实团队的水平。
示例输入：五人团队，迭代为两周共10个工作日。成员A、B为开发，各可用10天，每日有效工时6小时；成员C为测试，可用9天（休假1天），每日有效工时6小时；成员D为设计，可用8天（休假2天），每日有效工时5小时；成员E为开发，可用10天，其中2天需支援其他团队，按每日3小时计入。团队约定专注系数为0.8。历史数据显示，近三个迭代共完成60个标准任务，总耗时720小时，单位任务平均耗时为12小时。
| 成员 | 可用天数 | 每日有效工时 | 毛可用工时 |
|---|---|---|---|
| A | 10 | 6 | 60 |
| B | 10 | 6 | 60 |
| C | 9 | 6 | 54 |
| D | 8 | 5 | 40 |
| E | 10 | 3 | 30 |
| 合计 | — | — | 244 |
计算过程：毛可用工时合计244小时；乘专注系数0.8，净可用工时为244×0.8＝195.2小时；除以单位任务平均耗时12小时，容量为195.2÷12≈16.27，向下取整为16个标准任务。若团队约定在结果上再留10%缓冲，则承诺上限约为14个标准任务，剩余2个任务单位作为应对不确定性的余量。
结果解读：这个团队在本迭代可承诺的范围大致是14到16个标准任务，具体取哪个值取决于需求清晰度和外部干扰的预期。示例中的假设包括：专注系数0.8为团队约定值、单位任务平均耗时取自近三个迭代、成员E的支援安排已按比例折算。这些假设在真实使用时都需要用本团队数据替换，并用后续迭代的实际完成情况检验。
结果解读、校准与常见限制
容量算出来只是起点，需要用历史完成率校准。做法是取近几个迭代的容量估算值与实际完成量，计算完成率，观察偏差方向和幅度。如果连续多个迭代实际完成明显低于容量，说明专注系数偏高或分母偏小，应下调专注系数或重新核算单位任务平均耗时；如果实际完成持续接近甚至超过容量且团队长期加班，说明容量被低估，可适度上调。校准以多个迭代的趋势为准，不用单个迭代的偏差直接改参数。
偏差分析要区分原因。完成量低于容量，可能来自估算偏差、需求变更、外部支援或成员可用性变化，逐项对照记录才能判断该调哪个参数。完成量高于容量，也要确认是否以加班或降低质量为代价，避免把不可持续的状态当成正常水平。
容量是单指标，不能代表团队全部绩效。它反映投入与耗时的折算关系，不反映交付质量、需求价值、协作效率或技术债务状况。评估团队时应把容量与完成率、缺陷情况、需求交付周期等指标结合看，任何单一指标都不足以支撑对团队的整体判断。
未完成工作需要重新评估，不能默认结转。上个迭代未完成的事项进入新迭代时，要按新迭代的容量重新排优先级、重新确认估算，并检查是否因需求变化而需要拆分或取消。默认全部结转会让新迭代的承诺量虚高，容量计算也就失去约束意义。
常见限制还包括：团队人员结构变化较大时，历史平均耗时的参考价值下降；新类型任务缺少历史数据，分母只能估算；跨团队依赖多的场景，容量难以覆盖等待时间。这些情况下，容量结果应作为参考区间使用，并在规划会上结合团队判断调整，同时把调整原因记录下来，供下个迭代校准参考。
常见问题
团队第一次算容量，没有历史完成数据，分母怎么定？
分母为零或历史数据不足时，不建议强行套用公式。可以先用“人天”直接表达容量，即只计算净可用工时，在规划时用总量约束候选工作项；同时从当前迭代开始记录每个完成项的实际耗时，积累一到两个迭代后，再计算单位任务平均耗时并折算成任务单位。若任务类型差异大，可以按类型分别积累平均值，避免用一个笼统的分母覆盖所有工作。
专注系数应该设多少，设错了会怎样？
专注系数没有通用标准值，通常由团队根据历史观察约定，例如每日有效工时中真正用于迭代内交付的比例，并把取值依据、约定日期和约定人记录下来。设得偏高，容量会虚高，承诺量超出实际承受能力；设得偏低，容量被系统性低估，规划时容易漏排工作。判断是否合理的方法是用后续迭代的实际完成情况回看，连续多个迭代偏差方向一致时再调整，不用单次偏差直接改参数。
迭代中途有人请假或临时支援其他团队，容量要重算吗？
需要重算，至少重算剩余部分的容量。人员变动会改变可用天数或每日有效工时，按原容量继续承诺会让剩余工作超出实际投入。做法是用变动后的可用工时重新计算剩余迭代的容量，再对照剩余工作项判断是否需要调整范围：优先保留高优先级事项，把低优先级事项移出本迭代并重新评估，而不是靠加班消化差额。变动原因和调整结果建议记录，供下个迭代校准参考。
容量和速率都有，规划时以哪个为准？
两者用途不同，规划时结合使用。容量从投入侧推算本迭代理论上限，速率反映团队过去实际完成的工作量。常见做法是先算容量确定上限，再参考近几个迭代的速率判断承诺量是否现实，最终承诺量通常不超过容量，并留出缓冲。当容量明显高于历史速率时，要检查专注系数或分母是否偏乐观；当容量明显低于历史速率时，确认是否有可用性数据遗漏。两个指标出现持续背离，说明参数需要校准。
上个迭代没做完的工作，新迭代可以直接计入承诺量吗？
不能默认全部结转。未完成事项进入新迭代前，要按新迭代的容量重新排优先级、重新确认估算，并检查需求是否变化、是否需要拆分或取消。直接结转会让新迭代的承诺量虚高，容量计算也就失去约束作用。合理的做法是把未完成项与新增需求放在一起，按新迭代容量统一排序，超出容量的部分明确移出，并说明重新安排的依据。
