Scrum 的资源分配、团队速率估计和容量计算都需仔细规划与跟踪。就像传统项目管理中的项目订单（PO）管理，这项工作把细节决策集中到规划讨论中。
International Scrum Institute™ 的见解
敏捷 Scrum 团队容量规划：有效 Sprint 规划与团队成员速率的项目工作指南
容量规划需要注重细节和清晰方法。将流程可视化并使用实用策略与工具，复杂事情也会变简单。它对 Scrum 项目成功至关重要，但连资深 Scrum Master 也可能低估或误解它。
2024 年及以后，技术进步和直观项目管理工具扩展了团队能力，简化高质量服务交付。本分步指南通过示例介绍资源分配和容量计算，帮助避免常见陷阱、推进交付。下面探索 Scrum 容量规划与专注系数。
Scrum 能力规划
Scrum 容量规划概述
本指南介绍如何计算并分配 Sprint 内有效工程时间，涵盖操作顺序、人员可用性、待办项、工时和竞争优先级。结合指南与专家建议，团队能理解容量并预测现实工作量，适用于 Scrum Master、Product Owner 和团队成员。
Scrum 容量规划的重要性
Scrum 是迭代、增量开发和交付高质量产品的敏捷框架。工作在固定时长的 Sprint 内围绕 Sprint 目标开展。容量规划帮助团队理解工作量和预测可完成内容。承诺针对 Sprint 目标；选定工作是预测，可随认知增加而调整。
容量规划帮助团队及客户成功交付项目和服务，估算 Sprint 内可用的有效工程时间、制定现实目标，并更方便地跟踪交付进展。
在过载和负荷不足之间寻找平衡：前者可能导致压力和倦怠，后者降低生产力。明确可用时间和技能，帮助团队组织工作、最大化业务价值。
结合专家判断的容量规划可改进交付预测并管理利益相关者期望，减少延期、建立信任、估计功能或交付物完成时间。迭代规划也把错误转为学习机会。
像烘焙蛋糕一样，量好配料有助于实现想要的成果。Scrum 容量规划同样考虑人员技能和可用时间，再根据此前迭代的经验调整方法。
目标是现实目标、均衡负荷和更好预测。像精心调整配方，有效资源分配在关注大目标的同时，提高客户满意度、质量与效率。
容量规划工具与方法
有效容量规划支持良好项目管理、客户满意、质量和效率。确定 Sprint 可实现内容，有助于兼顾交付物与大目标。这一资源分配和执行工具可节省时间与金钱。Scrum 团队用于协作、规划和工作负荷管理的工具包括：
- Agilefant
- Atlassian JIRA
- Pivotal Tracker
- Microsoft Project Server
- Trello
这些工具支持协作、流程标准化、负荷管理、资源分配、优先级和绩效跟踪。请按团队所需能力选择。管理良好的项目能支持销售、避免错误、改善交付。
估算团队容量与速率
规划前，检查团队速率，即 Sprint 实际完成的估算工作量。Scrum Master 可帮助理解这一指标及局限。结合历史交付、当前可用时间与每个人职责，预测现实时间线、减少疏漏和成本、增强规划信心。
结合历史速率和当前可用时间指导预测。领导者应理解信息并支持规划。更准确的估算（参见 Scrum 投入估算）可在整个项目中增强对团队工作和容量的信任。
容量与历史速率相互参考，但不能互换。了解人员可用情况有助于解释过去交付并预测未来 Sprint，以改进工作流、支持业务与销售目标、从错误中学习。
团队容量取决于可用工时、休假、节假日、培训及其他承诺。理解这些需求和成本，可改进估算，并在迭代项目中建立信任。
现实估算帮助团队制定可达成目标、组织工作。高估可用时间可能导致交付价值低于预期，或过载倦怠，损失金钱与生产力。
项目全程比较估算与实际投入和成本，及时调整并吸取经验。细心组织、关注团队和客户需求变化，有助于避免重复错误。
Scrum 速率计算
Sprint 规划时，团队可结合历史速率与当前容量预测工作。速率是规划辅助，并非 Scrum 必需指标或个人绩效衡量。它帮助理解交付模式和组织工作，本身不定义任何人的角色。
使用故事点时，合计 Sprint 中达到完成定义的工作点数，即为速率。通过课程和文章持续学习，并帮助同事理解指标用法。更好规划可支持项目细节、投资回报和销售。
只在工作达到完成状态的 Sprint 中计入。排除未完成故事，包括未完成结转项，以及中途加入却仍未完成的工作。中途加入但结束前完成的工作应计入，这使指标有助于预测容量和讨论成本。
| Sprint | 故事数量 | 故事点 |
|---|---|---|
| Sprint 1 | 6 | 29 |
| Sprint 2 | 8 | 34 |
| Sprint 3 | 7 | 28 |
敏捷团队容量如何计算？
步骤 1：计算专注系数： 专注系数可描述可用工时中用于所规划活动的比例。单位必须兼容：若速率用故事点、容量用小时，“专注系数 = Sprint 速率 / 团队容量”并非无量纲比例。基于时间的系数应以有效工时除以总可用工时。
“专注系数 = 有效工时 / 可用工时”
Sprint 速率与燃尽图
步骤 2：计算 Sprint 速率： 速率是 Sprint 已完成的估算工作量。过去三至五次迭代平均值可帮助预测。可用团队时间应单独合计每个人可用天数或小时；只有人人可用情况相同时，人数乘天数才适用。
例如，团队每个 Sprint 平均完成 32 个故事点，6 名成员每天可用 8 小时。仅凭这些不能得出基于时间的专注系数。
“32 /(6*8) = 0.67” 将每个 Sprint 的故事点除以每天小时数，并不能证明团队时间的 0.67 可用于有效工作。
步骤 3：计算 Scrum 团队容量： 现在假设另行测得有效时间比例为 0.67。对于例如从 一月 1 日开始的 2 周 Sprint，适用时排除周六、周日，假设有 10 个工作日，同时检查本地节假日和个人可用情况。以此时间比例乘可用工时：
“团队容量为 0.67 * (6*8*10) = 321.6 小时”
在这些假设下，总可用 480 小时中，剩余 158.4（480 - 321.6）小时，可用于 Sprint 规划、Daily Scrum、Sprint 评审、Product Backlog 精化（有时称为梳理）、Sprint 回顾、休息、与 Product Owner 澄清故事等其他会议及需求。这是示例分配，不是故事点到小时的换算。
预测 Sprint 故事点时应考虑容量，避免无法实现的目标。原示例采用 0.6 至 0.8 的专注系数范围，只应视为假设，而非 Scrum 规则或通用基准。团队实测系数有助于估算增量工作时间、判断负荷是否可持续，但本身不能衡量团队健康。
故事点估算
故事点估算像规划长途旅行：无需预知所有路障，也能准备时间和资源。预估需求、成本和客户期望，再用团队适应能力处理不确定性、降成本、改善工作体验。
以数据洞见驱动的故事点估算是敏捷项目和 Scrum 会议规划的重要部分。它按复杂度而非耗时为用户故事赋值，更好满足客户需求，并使容量估算达到极高准确性。
团队常用类似斐波那契数列（1,2,3,5,8），结合经验与技术知识比较相对投入和复杂度。可按需在规划前或期间估算；Scrum 不规定此量表或时间。让实际执行者参与，以不同视角改进估算。
例如，登录功能设计与实现比网站标志更费力，为登录工作分配更多故事点是合理的。讨论差异有助于团队成长、项目成功和更好工作体验。
每个人的意见都可能揭示假设、改进估算。一些团队对个人投票加权平均，这只是本地技巧，并非 Scrum 要求，也不能替代讨论分歧。规划扑克应讨论不同估算背后的原因，形成共享估算。
故事点帮助理解复杂问题和预测开发工作。复杂度只是规划因素，不自动意味着最高优先级；还要考虑业务价值、依赖、风险和 Product Owner 的排序。
预见范围变化与调整
容量规划需要适应性：预见变化、准备调整，改善执行和组织运作。
若意外需求使计划不现实，应检查并适应。Developers 与 Product Owner 可随学习澄清和重新协商范围，而不危及 Sprint 目标。利益相关者反馈支持这些决策，使工作响应客户需求。
让范围变化透明，使所有人共享理解并有信心沟通。从启动到收尾始终维持这一共同认识，带来连贯工作体验。
将节假日与带薪休假纳入规划
估算时计入节假日和 PTO（带薪休假），调整预测，确保假期中 Sprint 目标仍现实。规划工具帮助理解日程、变化需求与可用情况，支持连续性、成本效率和客户服务。
例如，在八周规划期内休假两周的开发者，未计其他承诺前可用六周。这个规划期跨越多个 Sprint；一个 Scrum Sprint 最长一个月。规划每个 Sprint 时都要考虑 PTO 和个人承诺。
还应计入员工会议、培训、电子邮件等占用工时的活动，以现实规划、维持生产力和支持收入。
制定项目级日程时，明确工作并考虑容量与人员可用性。清楚定义任务，再由执行者自行组织。长期日程是预测，不能替代 Sprint 规划或 Developers 自我管理。
建立项目日程并排序
新软件工作可能包括需求收集、界面设计、编码、测试与部署。将大活动拆成小任务，便于随情况调整。像蛋糕配方，列明材料、数量和步骤，而非毫无计划地混在一起。
表格能直观显示任务、可用时间和预测时间线，将总体计划与进展及培训需求联系起来。下列时长仅为项目活动示例，不是强制顺序阶段或 Sprint 长度；每个 Sprint 应跨技能协作，创造可用增量。
时间有限、需求竞争时，决定哪些需立即关注、哪些可等。结合复杂度、业务价值与 Product Owner 排序，增强规划信心、支持业务成果与收入。
烘焙比喻中，午餐需要面包，就先做面包再做蛋糕。目的和时机指导顺序。安排任务和节假日时也用这种务实思考。
| 任务 | 资源 | 时长 |
|---|---|---|
| 收集需求 | Product Owner | 2 周 |
| 设计用户界面 | UI/UX 设计师 | 3 周 |
| 编码 | 开发人员 | 8 周 |
| 测试 | QA 团队 | 4 周 |
| 部署 | DevOps 工程师 | 1 周 |
随工作推进重审优先级。容量有限意味着按价值、复杂度和共同目标，选择立即处理与推迟的任务。
就像午餐前先做面包再做蛋糕，应解释顺序原因，让所有人理解计划。
预测任务及整个项目时，预留意外延误、挑战和培训。应变余量不足时，容量短缺可能导致挫折。
容量规划回顾
容量规划考虑可用时间、技能和外部依赖，预测 Sprint 现实工作量。《Scrum 指南》要求规划时考虑即将到来的容量，但不规定专注系数公式。以下为本文所列统计：
- 平均而言，采用 Scrum 容量规划的团队生产力提高 25%。
- 约 90% 的成功敏捷项目采用某种形式的 Scrum 容量规划。
- Scrum 容量规划使项目延误可能性降低 40%。
- 采用 Scrum 容量规划的团队报告总体项目成本降低 75%。
- 实施 Scrum 容量规划的组织客户满意度评分提高 15%。
容量规划考虑人数、技能、可用时间和其他承诺，估算 Sprint 可承担内容，支持有效资源使用与现实目标。项目中应随容量和需求变化持续监测、调整。
祝您的 Scrum 容量规划顺利。保持开放、检查实际情况、调整方法。持续改进的承诺能增强规划、推动成功。
感谢您投入学习 Scrum。祝您在专业成长路上一切顺利。
