敏捷项目管理工具的冲刺容量规划：人力、工时与承诺量怎么定

Sprint规划会如果开成任务认领会，容量失控往往就从这里开始。排期时把团队人数直接换算成可排期天数，忽略会议、值班、请假与依赖等待，承诺量从第一个冲刺就开始透支。很多团队并不缺工具，缺的是把容量、承诺与目标分开计算的次序。先算可用容量，再谈优先级，最后才决定承诺量；顺序一旦倒过来，计划就容易脱离实际。 下面按人力、工时、承诺量三个层次，说明冲刺容量规划怎么算、承诺量怎么定。

一、人力、工时、承诺量：三层含义先分清

冲刺容量规划最容易出错的地方，不是算错数，而是概念混用。人力、工时、承诺量分属三个层次，回答三个不同的问题。

1. 人力：回答谁来做、技能是否匹配

人力是角色与技能的组合，它决定一项工作有没有合适的人承接，本身却不是产能。一支10人团队，如果只有2人熟悉结算模块，那么结算相关需求的可用人力就是2人，而不是10人。先把人力映射到具体技能域，再计算产能，是避免容量虚高的第一道关口。

2. 工时：回答本周期能投入多少时间

工时有两个口径。名义工时是人数乘工作日，衡量在岗；有效工时是在名义工时里扣掉不可出勤时间之后的部分，衡量真正能排进需求的投入。两者的差额通常比想象中大，把名义工时当可用时间，是承诺量偏高的常见起点。

3. 承诺量：回答本次承诺交付什么

承诺量是在容量约束下选出的一组工作，它是结果，不是起点。承诺量的上限由有效容量决定，用承诺量倒推容量，只会把压力转移给加班和压缩测试。 在Scrum框架里，团队承诺的对象是目标而不是任务清单，这一点在第四部分展开。

下表用于区分三个概念各自回答的问题与常见误用。

三者的正确顺序是人力、工时、再到承诺量。

二、团队可用容量怎么算：一条公式与三个扣减项

团队可用容量的基本关系可以写成一条公式：可用容量＝团队人数×人均有效工作日×每日可投入时长×专注系数－已确认的非项目工作。这条公式的重点不在乘法，而在两个可调项：专注系数与已确认的非项目工作。其中的人均有效工作日只是便于理解的简化写法，实际计算应按成员逐人累加；公式算出的也只是总量，落到具体技能域时还要按人力结构切分。三个扣减项依次如下。

1. 先把名义工作日变成有效工作日

逐个成员登记可出勤天数，扣除法定节假日、年假、调休、培训、值班以及已确认的外部支持。这里应按人登记，而不是按团队取平均，因为休假分布并不均匀。如果按平均处理，一名即将连休两周的成员仍会被计入满额，误差在规划之初就出现了。

这一层只处理不可出勤的时间，会议和日常协作带来的损耗放到下一步。微软Azure Boards官方文档对容量的说明是：容量对应团队成员实际可用于任务的时间，需要计入休息日与休假，并按每个冲刺单独设置。这说明容量是逐冲刺、逐人估算的变量，而不是可以长期沿用的固定值。

2. 用专注系数折算协作损耗

专注系数处理的是另一类损耗：人虽然在场，时间却被会议、临时沟通和任务切换切碎。团队越分散、协作链路越长，取值通常越低。这个系数没有通用标准，应由团队用自身历史数据校准。 直接沿用其他团队的取值，结论容易失真。

3. 再扣掉已确认的非项目工作

最后一个扣减项，是已经确认且必然发生的额外任务，例如例行运维、跨团队共享资源的支持工作、关键人员的时间冲突处理。这些工作不会因为没写进计划就消失，只会在冲刺中途挤占容量。判断一项工作是否该提前扣除，可以用一个标准：它在冲刺期间一定会发生，且发生时间基本可预期。

下图概括了容量从总时间收缩到可投入时间的三个阶段。

举个计算示例：一名开发人员本周期有9个有效工作日，日均名义8小时，专注系数按团队历史数据取0.7，另有8小时值班任务，那么项目有效容量约为9×8×0.7－8＝42.4小时，约合5.3人天。排需求时应以这42.4小时为上界，而不是名义的72小时。

三、从可用容量换算到承诺量

算完容量，才轮到选工作。这一步的关键，是让承诺量与容量使用同一套口径。

1. 工时估算和故事点估算各管什么

故事点衡量相对规模，适合同一团队跨冲刺比较；工时，也就是人天，衡量真实投入，适合与容量直接对齐。容量是工时口径，承诺量要落到工时口径上才校验得起来。 如果团队习惯用故事点做规划，就需要一条换算基准：把历史完成点数与实际投入工时的比值固定下来，作为本团队的换算系数。用故事点估规模、却用人天拍承诺，两套口径互不对应，承诺量就失去了校验依据。

2. 用历史速度给承诺量设一个上限

历史速度是过去若干冲刺实际完成量的统计结果，用来给承诺量设上限参考。参考历史区间，不拿最好成绩当目标。 只取历史峰值作为本期目标，容易让承诺量偏高，而偏差往往在冲刺末期才暴露。历史速度不能直接当作本期承诺，但可以拦住明显超量的范围。

3. 承诺量要留出缓冲

把有效容量排满，等于假设本周期不会发生任何意外。常见做法是预留一部分应急空间，用于线上问题、依赖延迟与需求澄清。缓冲比例应与团队自身的偏差水平匹配，由历史数据校准，而不是随手定一个数字。 需要说明的是，承诺量要同时满足两个约束：不超过历史速度的参考上限，也不超过扣除缓冲后的有效容量，两者取更严格的那个。

四、把容量与承诺写进工具并持续校正

容量算得再准，如果只停留在表格里，也很难在冲刺中途起作用。

1. 容量要按冲刺维护，而不是一次算完

每个冲刺重新计算容量，并把假设一并记录下来：参与人、可用天数、专注系数、已扣事项。在敏捷项目管理工具里，可视化容量条的价值在于让接近满负荷和仍有余量的成员一眼可见，而不是为了把工时填满。 把假设写清楚还有一个作用：出现偏差时，团队能判断是系数取值不准，还是中途发生了未预料的工作。

2. 承诺的对象是冲刺目标，工作项可以调整

Scrum Guide 2020由Ken Schwaber与Jeff Sutherland共同维护，其中提到一个关键设定：冲刺积压的承诺是冲刺目标，而冲刺目标是本次冲刺的唯一目标。冲刺积压同时也包含本次从产品待办列表中选入的工作以及交付增量的执行计划，因此开发团队对外承诺的是目标，内部工作项可以随认知变化，与产品负责人协商调整。当容量被高估时，更稳妥的做法是与产品负责人重新协商范围，而不是默认加班补差额。

3. 每个冲刺复盘一次容量偏差

在回顾中比对计划容量、实际投入与实际完成。如果连续两个冲刺的偏差都超过团队自设阈值，就应调整专注系数或缓冲比例。 这些数据只有在敏捷项目管理工具中持续沉淀下来，复盘才有依据。面向规模化研发团队，禅道项目管理软件集项目管理、质量管理与效能管理于一体，可以承载容量与偏差数据，不必依赖手工统计，相关能力说明可参考禅道官网。

五、常见问题解答

团队同时参与多个项目，容量应该怎么算？按投入比例拆分，分别登记到各项目。同一个人不要在多个项目里都被记为满额，否则总容量会被重复计算。

冲刺已经开始，临时来了紧急需求，能直接加进本次冲刺吗？不建议直接叠加。先判断它是否影响冲刺目标：不影响时，可用同等工作量的项替换；影响目标时，应由产品负责人决定是替换原范围还是延后到下一个冲刺。

上一个冲刺没做完的事项，这个冲刺要直接占容量吗？不直接占用。没有达到团队约定完成标准的工作项，应退回产品待办列表重新排序，由产品负责人决定是否重新进入本次冲刺；只有被重新选入时，它才占用本冲刺容量。

工作项拆得比较粗，会不会影响容量判断？会。工作项越大，估算区间越宽，容量校验的意义就越小。通常把进入冲刺的工作项拆到一两天内可以完成或验证的粒度，估算更贴近实际。