Sprint规划怎么做？会议议程、角色与计划示例

Sprint 规划不是把待办事项尽量塞满，而是由整个 Scrum 团队共同确定这次 Sprint 为什么有价值、能完成什么，以及如何完成。会议结束时，应得到 Sprint 目标、选中的产品待办事项及实现计划，也就是 Sprint Backlog。目标明确、工作量有依据、关键依赖可见，比承诺一个看起来很满的任务列表更重要。

准备下一次规划时，可以先查看 Boardmix 敏捷看板模板，将目标、候选工作项、风险与待确认问题放在同一画布上，再由团队讨论取舍。看板帮助表达计划，但不替团队决定交付范围。

1. 什么是 Sprint 规划，应该产出什么？

Sprint 是 Scrum 中一个固定长度、最长不超过一个月的工作周期。Sprint Planning 开启这个周期，帮助团队把产品方向转化为本次可执行的计划。敏捷强调通过实际交付、检查和调整应对复杂工作，而不是要求开始时就精确预测之后所有细节。

按照《Scrum 指南》，规划围绕三个主题展开：为什么本次 Sprint 有价值、这次能做什么、所选工作将如何完成。产品负责人提出价值方向，开发者结合能力与既往表现选择工作并制定实现计划，整个团队共同形成 Sprint 目标；Scrum Master 帮助团队理解并有效开展 Scrum 事件。

可以把三个产出分别写在白板上：一句清楚的目标、围绕目标选出的工作项、完成这些工作所需的初步安排。如果只有任务名称，没有共同目标，团队很容易在遇到阻碍时各自赶进度，却不知道哪些事情必须优先保住。

2. Sprint 计划中容易混淆的六个概念

例如，“已登录会员能看到到期日期”是某个工作项的验收条件；团队约定的评审、测试与质量要求属于完成的定义。只满足业务条件但未达到共同质量标准，不能仅因展示出来了就视作完成。

用户故事可以写成“作为会员，我希望在账户页看到到期日期，以便安排续费”，但格式完整不等于需求清晰。还要说明日期从哪里来、没有有效会员身份时展示什么、哪些情形不在本次范围。用户故事地图可以将注册、开通、使用、续费这些活动并排放置，帮助团队讨论一次可用体验应包含哪些内容。

3. 如何组织 Sprint 规划会议：六项关键安排

3.1 围绕“为什么、做什么、怎么做”展开

先讨论这次要给用户或业务带来什么变化，再选择工作项，最后讨论实现方式。不要用逐人汇报占满规划会议。“谁来做”可以在实现计划中协商，但不能取代价值目标。开发者需要有空间说明技术依赖、测试工作和不确定性，而不是被动接受已经排好的任务。

3.2 会前准备材料，让在线协作承接实际问题

产品负责人准备有序的候选条目和价值背景，开发者准备能力、假期、支持任务及已知依赖信息。团队应在日常持续细化待办项，避免把会议变成第一次阅读所有需求。Atlassian 的 Sprint 规划实践也强调会前准备与明确输入、输出的重要性。

在 Boardmix 中，可按“目标、候选工作、容量约束、待确认问题、所选工作”分区，把需求说明、截图和评论与相应条目放在一起。远程成员共同打开画布，先补充问题，再集中讨论差异。通话使用团队已经配置的会议工具即可，不需要为了规划会议迁移整套沟通系统。

3.3 正确理解时间盒，不把两小时当统一规定

《Scrum 指南》规定，一个月 Sprint 的规划会议最长为八小时，较短 Sprint 的会议通常更短；它没有规定“两周 Sprint 一律最多两小时”。团队可以按工作复杂度安排议程，但应在时间盒内形成必要计划，不追求将每一个实现细节都提前确定。

如果时间被大量未澄清需求占用，应将影响选择的关键问题解决或标记为暂不纳入，而不是延长会议直到所有人疲惫。会后可复盘：耗时主要来自目标分歧、需求细节不足，还是技术依赖尚未确认，再改善下一轮准备。

3.4 用目标约束范围，不用任务数量代替价值

“完成十张卡片”通常不能解释用户会获得什么。“让即将到期的会员知道状态并找到续费入口”更便于讨论优先级。遇到容量不足时，团队可以围绕目标重新协商具体范围，而不是把每项工作都视作同等重要。预测工作量时参考既往完成情况，但不要把不同团队的故事点当作可直接比较的产能单位。

3.5 细化用户故事，带着验收问题讨论

拆分应尽量得到可理解、可检查的结果，而不仅是“前端开发、后端开发、测试”三个部门任务。围绕一个用户活动提出验收问题：谁可使用、何时可见、成功是什么、失败如何反馈。这些问题帮助团队发现隐藏工作，也让估算更有依据。

用户活动较多时，可以先整理用户故事地图模板中的主线与分支，再选出本次目标需要的范围。模板展示的是组织方式，具体活动、故事及验收条件必须来自当前产品。

3.6 为未知与回顾留出位置

能力不是人数乘以工作日后得到的一张满负荷表。请同时考虑维护支持、评审测试、跨团队依赖和已知缺席。遇到尚不清楚的技术问题，可安排有明确问题、时限与输出的探索工作；不要把“研究一下”当作没有结束标准的占位符。

上次 Sprint 的实际完成情况可以帮助形成预测，回顾会中的过程改进行动也可以影响本次安排。Sprint Review 关注产品增量与后续方向，Sprint Retrospective 关注团队如何改进工作，两者不能用同一张模板混代。

需要讨论协作中的障碍，可在单独的Scrum 迭代回顾会模板中记录原因与改进行动，再将已确认的改进带入之后的规划。

4. 演示：把会员续费目标变成一份可讨论的计划

假设一个产品团队准备改善会员到期后的续费体验。已有反馈是“用户不知道什么时候到期，也不知道从哪里续费”。这只是教学场景，不代表实际客户研究结果；真实项目应带上反馈记录、规则与已有使用数据。

Sprint 目标示例：让即将到期的会员在账户页确认会员状态，并能进入正确的续费流程。暂不处理优惠活动、会员推荐和整个支付系统改版，防止同一个目标不断膨胀。

接着由开发者讨论实现和验证工作，例如确认会员接口、调整状态展示、补充分支测试。将“支付接口交付时间未确认”写为依赖，而不是默认它会按时出现。团队需要选择一个可行方案：确认依赖后纳入、调整交付切片，或重新协商目标，不应只给该卡片换成绿色。

落到画布上，可将所选条目转为带人员、时间、标签的卡片，并在看板中组织状态。Boardmix 卡片看板帮助说明了卡片拖入看板、分组和筛选等操作。它们让工作可见；工作是否达到验收条件、是否满足 DoD，仍需要团队确认。

5. 规划结束前，怎样判断已经可以开始工作？

• 目标可复述：成员能够用自己的话说出本次要改善的结果，而不只是读出任务清单。
• 范围有理由：能解释选择哪些工作、暂缓哪些工作，以及它们与目标的关系。
• 能力已考虑：假期、维护、测试与关键依赖没有被遗漏，未确认部分有负责人。
• 实现能起步：开发者知道接下来如何推进，复杂细节允许在工作中继续调整。
• 完成可检查：条目的验收条件与团队 DoD 都可找到，不靠临时口头解释。

规划不是对所有任务作不可更改的保证。执行中获得新信息，应在不危及 Sprint 目标的前提下与产品负责人澄清和协商范围，并让计划保持可见。若主要问题是无法评估依赖与影响，可继续阅读项目风险评估与应对记录；若会议总是无法形成结论，可参考需求评审会议的行动项示例。

下一次规划可以从Boardmix 敏捷看板模板开始，先填本次目标和一个候选条目，再邀请团队把验收条件、依赖和取舍补充完整。