Sprint容量规划：实用操作指南
Sprint容量规划是确定Scrum团队在Sprint中能够实际承诺多少工作的过程，考虑到将可用的团队成员和需要完成的工作。它是Sprint规划的输入之一，与产品Backlog和团队速率并列。不进行容量规划的团队要么过度承诺（承担超出其完成能力的工作），要么承诺不足（留下未使用的产能）。两者都是良好容量规划可以预防的问题。以下是Sprint容量规划的实用指南。
第一步：确定谁可用
容量规划的第一个输入是团队可用性。对于每个团队成员，确定他们在即将到来的Sprint中有多少天可以用于Sprint工作。考虑：计划休假和公共假期、非Sprint活动（支持生产问题、参加组织级会议、培训），以及对团队的任何兼职分配。
第二步：计算可用小时或点数
将可用天数转换为可用小时数。 如果团队成员在两周Sprint的10个工作日中有8天可用，他们有8天的容量。如果团队为规划目的使用8小时工作日，这是该团队成员64小时的容量。
应用专注系数。 并非所有可用小时都是Sprint工作小时。对大多数团队来说，70到80%的专注系数是合理的起点：64可用小时 x 0.75 = 该团队成员48个有效Sprint小时。
在团队中求和。 将所有团队成员的有效Sprint小时（或故事点，如果团队以点估算）加起来，得到总Sprint容量。
第三步：使用容量约束Sprint规划
将选定的Sprint Backlog条目与Sprint容量进行比较。如果选定条目的估算工作量超过Sprint容量，从Sprint Backlog中删除条目，直到计划在容量范围内。
使用历史速率作为合理性检查，而非替代品。如果团队过去五个Sprint的平均速率是40个故事点，而这个Sprint的容量计算产生等同于55个故事点的容量，计算中有些不对——容量估算应该在承诺55点之前进行调查。
在Sprint中间点审查容量。在Sprint中间点明显领先于计划的团队可能低估了容量；明显落后的团队可能高估了容量。中间点检查是在Sprint内调整计划的机会，而非等待回顾会议。
XNM协助公共部门组织建立有效的Scrum团队实践，包括Sprint规划和容量管理。欢迎联系XNM项目群与项目交付咨询团队，探讨贵团队的Sprint容量规划和敏捷交付。