原文作者：Sjoerd Nijland
原文地址：https://medium.com/serious-scrum/the-sprint-planning-c24df3e09779
翻译：柴晓燕&付新圆
对于敏捷中的活动有很多，本文先从Sprint计划开始，分享一些方法、建议和注意事项，这些对理解和实践Scrum都很有帮助。
Who？
Sprint计划的参与者：整个Scrum团队。
请注意，Sprint计划是一个积极的、合作的活动。如果需要的话，大家可以随意走动查找资料或解决问题。开发团队可以召集其他人来帮忙，在会议期间能收集到更多信息。
“开发团队还可以邀请其他人参加，以提供技术或领域建议。” — Scrum指南
参与性
并不是每位成员都会在参与活动时表现出积极主动和创造性，有些成员只有在感到自信或舒服时才会加入。
出勤率和参与度低都会降低透明度，并带来风险。Scrum Master认为每个人都参加和参与是他们的责任。
“ Scrum Master可以确保活动进行，并确保参与者了解其目的。” — Scrum指南
我认为，解释出勤和参与的价值，同时创造一个舒适、愉快、平静和尊重的环境，是Scrum Master 激励团队成员参与的最佳方法。
“给他们提供所需的环境和支持，并信任他们来完成工作。” —敏捷宣言。
有时，参与者可能会占据主导地位，并试图利用一事件来指导和影响团队的方向。这些输入可能非常有价值，但可能会妨碍其他人添加宝贵的输入，参与者应该意识到这一点。当团队成员之间发生不尊重甚至敌对时，Scrum Master应该及时介入。团队要把Scrum Master视为教练，以保护团队环境的安全。
When?
Sprint计划发生在什么时候： Sprint的开始。
这其实是一个很难回答的问题，《Scrum指南》并没有明确指出Sprint计划必须在一开始就进行。 事实上，如果准确地解释的话，在Sprint计划期间计划的工作指的是即将到来的Sprint，而不是当前的或这个Sprint。 Sprint计划不会在两者之间进行，因为Sprint在上一个Sprint结束后立即开始。请记住，Sprint充当的是事件的容器。
《Scrum指南》暗示了这一点。
“每个人都在另一个Sprint中重新组合，计划开始另一个Sprint” —《 Scrum指南》。
幸运的是，Scrum.org的Scrum词汇表更加具体：
“Sprint计划：定时活动，以开始Sprint。” — Scrum词汇表
团队在优化期间准备Sprint计划并不少见。总的来说，Sprint计划在一致的时间和地方开始。
How long ?
如果进行长度为一个月的冲刺，最多需要8个小时来进行冲刺计划 。对于周期短的冲刺， 则花费的时间更少。
团队通常会根据sprint的周期来制定迭代计划 ，一个星期的Sprint可能 需要2个小时的计划时间。请记住，这只是最大时间，没有最小时间。经验丰富的团队很可能在时限到期之前完成计划 。
好的协作与改进能促使sprint计划会议更加迅速，更加有效。就是说，时间并不能决定解决问题的效率 。
准备
Sprint计划时我们要准备以下内容 ：
- 来自Sprint回顾会的反馈和有价值的输入内容 （可能已经加入到产品待办事项列表中）
- 完善的产品待办列表
- 在上次迭代回顾会议上确定的至少一项 优先级较高的流程改进
- 讨论Sprint的潜在目标
- “完成”的标准，即验收标准。
- 最近一次的产品增量
- 最近一次迭代开发团队的表现
- 冲刺期间开发团队的预计容量
在我的项目中，团队经历了很多次迭代 ，成员们都在呼吁推迟Sprint计划，他们要么不认为上一个Sprint已经完成，要么觉得自己准备不充分 。
那么， 上一个Sprint中 未被认 为“完成”的工作可以重新 规划 到下一个Sprint中。 请记住一个冲刺规定的时间范围结束标志着这个冲刺的结束，当然取消冲刺除外。
无论哪种情况，Sprint计划都不会推迟。如果在Sprint计划之前，上述所有内容都不是透明的，那么Sprint计划的时间范围可能允许在计划期间创造这种透明性。
Ready的解释
一些团队使用“ Ready ”的定义。Scrum仅规定了一个定义（尽管这并不排除团队引入诸如 INVEST标准之类的其他定义）：
“可以由开发团队在一个Sprint内“完成”的产品Backlog项被认为是“准备好”的，可以在Sprint计划中进行选择。”—Scrum指南。
目的
“在Sprint计划结束时，开发团队应该能够向产品负责人和Scrum Master解释其打算如何作为自组织团队来实现Sprint目标并创建预期的增量。” — Scrum指南
并且 ：
“ 开发团队在Sprint 的第一天 计划的工作将在本次会议结束前被分解。” — Scrum指南（强调）
如果实现了此目的，就达到了Sprint计划的目的 。
为了实现此目的，Sprint计划分为两个部分：
1.此Sprint可以做什么？
Scrum团队共同的 Sprint目标 应该达成一致。 产品负责人不指定Sprint目标，而是讨论Sprint应该实现的目标。最开始的时候团队需要透明性， 每个人对Sprint的目的的理解都需要保持一致。Sprint目标为开发团队选择实施的目标提供了一定程度的灵活性。冲刺目标可能雄心勃勃（毕竟这是一个目标），并有促进集体协作的作用。
产品负责人也将讨论产品待办事项，如果这些事项在Sprint中完成，将达到Sprint目标。
然后，开发团队将创建一个 Forecast （预测） ，这是对产品待办事项的初步选择，基于对产品的认识可以在Sprint中完成任务以达到Sprint目标。
“只有开发团队才能评估在即将到来的Sprint中可以完成的工作。” — Scrum指南
开发团队可以要求产品负责人说明并重新协商这些待办事项 。
在第一个Sprint的末尾，开发团队应该了解为什么要构建增量。
2.所选工作将如何完成？
当协调一致时，开发团队将制定一个交付的初始计划。 这些内容就是Sprint Backlog，它将在整个Sprint中继续出现。请记住，这还包括来自 最近一次 Sprint回顾 会 的改进计划。
温馨提示：预测并非承诺。开发团队创建的预测，应有效的去实施或对有价值的更改进行实践。 虽然开发团队作为专业人员承诺尽其所能， 但质量目标不应降低， 团队也不应为了实现预测而在“完成”的定义上偷工减料。
在此活动中，开发团队可能已经自组织并承担了工作：
“开发团队在Sprint计划期间以及整个Sprint中根据需要自行组织以进行Sprint Backlog中的工作。” — Scrum指南
透明性
除了为Sprint计划准备输入之外， 团队还有很多方法来完成Sprint计划。在Sprint计划期间，团队的力量在工作中的汇报是显而易见的。
团队来决定如何最好地推动Sprint计划，是非常关键的。
“流程中最重要的是必须对负责结果的人员 可见 。” — Scrum指南
并且 ：
“产品负责人的决定在产品待办事项列表的内容和 序列中 可见 。” — Scrum指南
更重要的是：
“ Sprint待办事项是开发团队计划在Sprint期间完成的工作的 高度可见的 实时 影像 ” —《 Scrum指南》
也就是说，我要提醒大家不要仅仅依赖电子看板来实现这种透明性：
有些糟糕的设置，例如：“ 团队会不耐烦地、漫不经心地围坐在一张桌子旁，桌子上的大屏幕正显示着电子看板，团队们 紧盯 着一个人按照指示更新看板…”
S.W.O.T
团队可以考虑的非Scrum技术是一个SWOT画布，在这个画布上，团队可以使重要因素变得透明。依赖关系会带来风险，因此可以在sprint期间跟踪它们。
当然，在Sprint过程中，也会发现或引入新的威胁，如障碍物。Sprint计划可以帮助团队为当时已知的事情做准备，也需要考虑到它未来可能遇到的未知挑战。
分歧
一致性，是我认为的任何Scrum活动的目的（即使Scrum指南中没有使用这个术语），仔细的检查能使团队在实际情况上保持一致，从而形成共同的理解。
通常，在Sprint计划期间会讨论许多主题，如果不是所有成员都在场，或者输入内容不透明，那么团队可能就会做出错误的假设，沟通不畅，从而导致团队不协调。产生了分歧将无法做出最佳决策，从而引入风险且价值无法最大化。
有时候，Scrum团队成员很难真正地在Sprint目标、预测或如何进行工作的计划上保持一致。与任何事件一样，每个人都必须遵守Scrum价值观，每个人都应该能够以尊重的方式表达自己的想法，不同的观点是学习的机会。当团队不能就如何同意或不同意达成一致时，这将在整个开发过程中造成严重的中断。
自组织团队需要学会平和的处理分歧。“不同意但承诺”是团队可以同意的潜在原则，但这可能并不适合每个团队。因此，有多种方法可以达成共识。为了快速检测是否达成共识，团队可以采用诸如 使用手势这样的方式。
请记住，仅在Sprint的第一天就计划好工作就足够了。
Scrum Master对 Sprint计划的作用
作为Scrum Master，可以试着验证团队中每个人是否理解Sprint的目的和方法，并且支持Sprint。
整个团队是否了解如何协作？信心水平是多少？他们实际上是在承诺还是在默默地服从？
从Sprint计划结束时的氛围来看，Scrum Master通常已经可以在某种程度上预测整个Sprint的期望。
请记住，这仅仅是开始。随着Sprint的进步和更多的知识，计划必须进行调整，并且团队的自我组织，实现Sprint目标或创造预期增量的能力可能会受到挑战。
另外，作为Scrum Master，提醒Scrum团队他们的改进目标很重要，在制定计划时也要考虑到这一点。
Sprint计划在其时间范围到期时结束，或者如果事件的目的实现了，则可以提前结束。