译者导读：

本文用简单易懂的方式，讲述了Sprint计划的核心要点和实际做法。它表达的关键是：做好Sprint计划，绝不是简单从待办列表里挑任务就行 —— 本质上，这是团队在 “确定的目标” 和 “不确定的变量” 之间找平衡，最终为实现共同目标做出靠谱承诺的重要协作环节。

要让Sprint计划真正管用，得在几个方面做好平衡：一方面要靠 “Sprint目标” 把方向定准，不跑偏；另一方面得把产品待办事项（PBI）拆解得足够细，确保能落地执行；既要做够技术设计，让大家对怎么做有底气，又不能设计得太复杂，避免白费功夫；既要遵守 “时间盒” 的时间限制，不拖延，也要留出让工作持续优化的空间。

而Sprint计划更深层的意义，在于让团队更齐心、彼此更信任。这么做不只是为了高效交付有价值的成果，也是因为团队对自己做的产品有自豪感，对工作有专业追求。

一个Sprint 应该产出一个定期产品增量。然而，简单地从产品待办列表顶部拉取PBI，并不一定会带来创造¶93 最大价值的工作，或者适合Sprint的时间盒来产生产品增量的工作。

任务之间通常是相互依赖的，并且基于团队对当前产品状态和业务领域的了解，他们可能会发现，在开发功能特性Q之前开发功能特性P，或者先执行任务X再执行任务Y，可以节省时间。  

¶7 Scrum团队 作为一个整体，通常无法足够详细地理解PBI，从而无法完全规定¶14 开发团队 如何实现它们。事实上，将PBI设计到那种详细程度是一种浪费，因为PBI可能会排队等待一段时间，并且业务和团队环境可能会随时发生变化，使得团队投入在PBI上的所有工作变得无关紧要。或者其他的PBI可能会进入产品待办列表，可能无限期地推迟某些PBI。但开发团队进行一定的设计思考是必要的，以便考虑如何实现给定的PBI。如果他们这样做得太早，那么这些计划可能会过时，而他们也不想计划得太晚。

随着开发团队成员对业务需求和技术限制的了解加深，他们可能需要在Sprint期间调整工作计划。这在处理大型单体PBI时尤为困难。

因此：

在每个Sprint开始时，Scrum团队（或所有共同交付共同开发产品增量的团队）召开Sprint计划会议，来规划如何在该Sprint内创造价值。团队选定¶71 Sprint目标，并制定关于开发团队要完成什么工作及如何完成这些工作的计划。这要求Scrum团队进行足够详细的解决方案设计，从而对如何构建产品抱有高度的信心，同时也要求团队成员确信他们能够在Sprint期间完成工作计划（参见 ¶59 颗粒度梯度）。

Sprint计划是Sprint的首要活动，它是价值流中，将产品待办列表转化为开发团队工作计划的关键衔接。

在Sprint计划期间，Scrum团队创建了Sprint目标，并产出了¶72 Sprint待办列表 的初始版本。一个附带产出是更新后的产品待办列表。如果在Sprint计划开始时，产品待办列表还是一个尚未完全细化好的待办列表（也许是因为¶11 产品负责人自上次与开发团队会面后，在PBI顶部附近增加了新事项），那么Scrum团队就需要讨论、估算、分解并排序新的PBI，为即将到来的Sprint工作计划做准备。

Sprint计划的主要活动包括：让团队确保产品待办列表已经准备就绪（参见¶65 就绪的定义）；就Sprint目标达成共识；选择团队预测可以在本次Sprint中交付的PBI；并规划如何开展工作并实现Sprint目标。大多数团队认为最好同时进行这些活动 - 例如，弄清楚如何开展工作有助于了解其范围和所需的工作量（速率可以有效地预测开发团队在一个Sprint中可以完成的工作量；请参阅关于速率的说明（第320页））。这自然影响开发团队在一个Sprint中能完成的工作量。

重要的是，Sprint计划要留出足够的时间进行设计，以便创建易于理解的Sprint待办列表。但计划应有时间限制。一个经验法则是，对于为期两周的Sprint，Sprint计划会议的时间不应该超过四个小时；对于较短的Sprint，则应相对减少。如果时间过长，就需要寻求改善的机会以减少计划的时间，并相应地增加产品构建的时间。

如果产品负责人没有充分细化开发团队所需的PBI以使团队不能够设计相关的¶73 Sprint待办事项，那么开发团队就不应在Sprint中接受它（参见¶63 启用性规范 或 就绪的定义）。未充分细化的PBI是工作量膨胀和Sprint失败的主要原因。Jeff Sutherland报告过一个Scrum团队，该团队有一个固定的规则，如果PBI没有被充分的细化，整个团队就将放假。（这是向产品负责人清晰地传达了关于产品待办列表的明确信息！）

Sprint计划会议的一项关键输出是开发团队应该能够阐述如何实现Sprint目标。如果他们能阐述自己的工作，这是一个很好的迹象，表明他们已经就此进行了充分的讨论，并达到了一个良好的理解水平，提高了团队在预估时间内完成目标的可能性。团队可以将此作为衡量会议有效性的标准之一。

如上所述，Sprint计划会议生成Sprint待办列表的初始版本，这是开发团队在Sprint中工作的初始计划，并在¶29 每日站会上对其进行细化和调整，每日站会本质上是一项每日进行重新规划的活动。

Sprint计划会议的质量对后续每日站会的成功有很大的影响。如果Sprint目标和Sprint待办列表定义清晰且易于理解，开发团队就更有可能有效地进行每日站会，且任何必要的重新计划也会清晰明了。低质量的Sprint计划活动可能增加多团队周期性进行的¶34 Scrum of Scrums 的负担。

Sprint计划会议的明显输出是Sprint待办列表和Sprint目标。但Sprint计划会议也能加强¶117 统一目标（第468页），促进开发团队和产品负责人更好地理解彼此的需求和动机。从而巩固了 ¶95 信任社区（第466页），并培育了 ¶3 沃土。

团队打磨待办列表不仅是为了争取最大价值，也是出于纯粹的¶38 产品自豪感。