Sprint Planning（迭代计划会）是 Scrum 团队在每个迭代（Sprint）开始时召开的规划会议，目标是回答三个问题：这个迭代要做什么（Sprint Goal）、从待办列表里选哪些条目（Sprint Backlog）、每条怎么做（拆任务与方案）。 会议结束时，团队带着一份明确的迭代目标和任务清单开工。
30 秒版
- 频率：每个 Sprint 一次，固定在迭代第一天；
- 时长：Sprint 每两周开一次 → 计划会不超过 2 小时；一周一个 Sprint → 1 小时；
- 参与者：整个 Scrum 团队——开发、Product Owner、Scrum Master；
- 产出：1 个 Sprint Goal + 1 份 Sprint Backlog（已拆解、可执行的任务）；
- 判断标准：散会后每个成员能不看文档说出「这个迭代我们做哪几件事」。
Sprint Planning 在迭代中的位置
Sprint Planning（第1天）
↓
每日站会（Daily Standup）× 9 天
↓
Sprint Review（评审演示）+ Sprint Retrospective（回顾会）
↓
下一个 Sprint Planning
计划会是迭代的起点，它消费上一步的产出：Product Backlog（产品待办列表）和上次回顾会（Retrospective）的改进项。两者关系见 Sprint 回顾会指南。
会前准备（决定会议效率的一半）
| 准备项 |
责任人 |
标准 |
| Product Backlog 已排序 |
Product Owner |
Top 候选条目足够清晰，无需现场解释需求背景 |
| 候选条目已梳理 |
Product Owner + 开发 |
头部 1.5~2 倍容量的条目已完成拆解/估点 |
| 团队容量已算 |
Scrum Master |
扣除请假、会议、值班后的有效人天 |
| 上迭代遗留明确 |
开发 |
未完成项：退回 Backlog 还是带入本迭代，会前有结论 |
| Definition of Done 就绪 |
团队 |
「完成」的标准团队一致认可 |
没有准备好的 Backlog，计划会就会变成需求澄清会——这是会议超时最常见的原因。
会议议程模板（以两周 Sprint、2 小时为例）
| 时间 |
环节 |
做什么 |
| 0:00–0:10 |
定目标 |
PO 提出本迭代想达成的业务结果，团队讨论收敛成一句话的 Sprint Goal（例：「让管理员能导出报表」） |
| 0:10–0:50 |
选条目 |
按 Backlog 顺序过候选条目：这条做不做、放进本迭代吗？结合容量做减法，直到容量用满 |
| 0:50–1:40 |
拆任务 |
对每个入选条目拆出 0.5~1 天粒度的任务，指明技术方案要点；有分歧的技术风险项当场确认方案 |
| 1:40–1:55 |
风险与依赖 |
盘点外部依赖（第三方接口、设计稿、其他团队）、值班安排、已知 Bug 的处理优先级 |
| 1:55–2:00 |
确认与承诺 |
复述 Sprint Goal 和条目清单，全员确认；明确第一天的启动任务 |
三个关键输入的计算方法
1. 容量（Capacity）
有效人天 = 成员数 × 工作日数 − 请假 − 会议开销 − 值班折算
例：5 人团队、10 个工作日、共请假 3 天、固定会议约折 2 人天 → 有效人天 45 − 3 − 2 = 40。
2. 速度（Velocity）
取最近 3~5 个 Sprint 完成故事点的平均或中位数（中位数更抗波动）。新团队没有历史数据时，用容量估算：1 人天 ≈ 1 个「有效工作量单位」，跑两个迭代后再切换到故事点。关于速度指标的理解误区见文末 FAQ。
3. 估点（Estimation）
- 常用规划扑克（Planning Poker）：全员亮牌，分歧大的条目讨论后重估；
- 估点估的是相对工作量，不是工时，不要用来考核个人。
常见错误与纠正
| 错误 |
后果 |
纠正 |
| 按容量 100% 排任务 |
没有任何缓冲，插个 Bug 就崩 |
排到容量的 80%，留出意外缺陷与协作开销 |
| PO 只在会上口头讲需求 |
会议变成需求澄清会 |
会前完成条目梳理，会上只确认不科普 |
| 只选条目不拆任务 |
「怎么做」留到开发时才想，迭代中途爆雷 |
拆到 0.5~1 天粒度并过一遍技术方案 |
| 目标是条目清单不是业务结果 |
团队只对「做完」负责，不对「有用」负责 |
Sprint Goal 必须是一句业务导向的话 |
| 上迭代 Bug 没定优先级 |
本迭代计划被临时缺陷打乱 |
计划会上明确遗留缺陷的处置（详见下节） |
迭代中的 Bug 放进哪里
计划会常被忽略的一环：这个迭代要处理哪些缺陷、谁的分诊机制在跑。建议在会上明确：
上迭代遗留缺陷的清单与去向（修 / 降级 / 关闭）；
迭代进行中新增缺陷的流程：分诊 → 定级（P0 当天处理，P1 排入本迭代，P2 进 Backlog）。分诊怎么做见 Bug Triage 指南；
缺陷报告的入口统一：让测试或用户提交的报告自带复现步骤、截图和 Console 报错，而不是散落在群聊里。
第 3 点是迭代速度的隐形杠杆：Bug 报告上下文完整，开发者拿到就能开工，不用来回追问。BugCapturer 在这一步的做法是——提交反馈时自动附带标注截图/录屏、URL、浏览器环境与 Console/Network 报错（见诊断功能），报告自动推送进 Slack / Microsoft Teams 频道，计划会分缺陷时直接按频道里的报告定级，不花会议时间对齐「这是个什么问题」。
FAQ
Q：Sprint Planning 是什么会议？
A：Scrum 中每个迭代开头的规划会，决定迭代的范围（做什么）与方案（怎么做），输出 Sprint Goal 和 Sprint Backlog。
Q：商业分析师（BA）视角下 Sprint Planning 是什么？
A：BA 关注的是需求的可测性与验收标准：确保入选条目带验收条件、边界场景明确，并负责把外部干系人的需求转成 Backlog 条目。
Q：计划会该开多久？
A：经验法则是每个迭代周最多 1 小时：一周迭代 1 小时，两周迭代 2 小时。超时通常说明会前梳理不足。
Q：远程团队怎么开计划会？
A：照常视频 + 共享看板（Jira/Linear/Trello），拆任务环节用协作白板并行写，比串行口头过条目快一倍。
Q：Sprint 中途发现计划排少了怎么办？
A：不要中途往里塞条目。记下来，在下一个计划会优先排入；紧急的走 P0 分诊通道。