正文
在开始Sprint计划会之前，团队已经定义并细化了产品待办事项列表，产品待办事项列表项(PBIs)仍然只代表潜在的价值。只有当开发团队使之成为现实时，它们才能产生价值(即移动到价值流的末尾)。您已经准备好开始一个Sprint，选择开发一个或多个PBIs来创建一个潜在的可交付的产品增量。
✥ ✥ ✥
一个Sprint应该产生一个潜在的可交付产品增量。然而，简单地将PBIs从产品待办事项列表中移除，并不一定会创造出最大的价值; 在符合Sprint时间盒子内完成工作也不一定能产生产品增量。
如果能始终从产品待办事项列表的顶部开始工作，而不用担心工作顺序，那就太好了，但是有几个原因通常不会发生。PBIs的大小并不统一，团队必须在Sprint的时间范围内创建可交付的产品增量。所以团队必须弄清楚什么是大小适合的，他们可能需要调整PBI顺序，甚至可能调整一些PBI内容。
Tasks通常是相互依赖的，并且考虑到团队对当前产品状态和领域的了解，团队可能会意识到，在特性Q之前开发特性P，或者在Task Y之前完成Task X，可以节省时间。
Scrum团队作为一个整体，如果对PBIs的理解通常不够详细，那么就无法说出将如何实现它们。但是在现实实践中，将PBIs设计到这个详细程度是一种浪费，因为PBIs可能会在未开发的情况下排队等待一段时间，而业务场景和团队知识可能会随着时间的推移而变化，这使得您投入到细化PBIs中的所有工作都变得无用了。与此同时一些PBI可能会进入产品Backlog，也可能会无限期推迟一些PBI。一些设计思考是为了让开发人员考虑他们将如何实现一个给定的PBI。如果他们做得太早，这些计划可能变的过时了，同时团队也不想一切计划得太晚。
开发团队成员可能需要在Sprint期间调整他们的工作计划，因为他们开始更多地了解业务需求和技术约束。在实现大型单个PBIs时，这是很困难的。
因此:
在每个Sprint的开始阶段，Scrum团队(或所有共同交付产品增量的团队)会聚在一起，计划如何在Sprint中创造价值。团队同意Sprint目标，并为开发团队将开发什么以及如何开发制定计划。这要求Scrum团队对解决方案进行足够详细的设计，以对如何构建产品有高度的信心，并要求团队成员觉得他们可以在Sprint期间完成他们的工作计划。
Sprint计划会是Sprint中的初始活动。它构建起产品Backlog和开发团队的工作计划之间的价值流。
在Sprint计划过程中，Scrum团队创建迭代目标，并生成Sprint Backlog的初始版本。附带的输出是更新的产品待办事项列表(PBIs)。如果产品待办事项列表在Sprint计划会的开始前还没有被梳理过(可能因为产品负责人在上次和和团队梳理之后又往待办事项列表的顶部附近增加了新项目),然后Scrum团队通过讨论、估算、分解、排序等为新PBIs制定计划，看是否能够放入即将到来的Sprint中。
Sprint计划的主要活动是团队确保产品待办事项列表已经就绪(Definition of Ready DoR);在Sprint目标上达成共识;团队预测在本次Sprint中可以交付的PBIs;并计划如何做这些工作项并实现Sprint目标。大多数团队发现最好同时进行这些活动。例如，弄清楚如何进行工作可以帮助您理解其范围和所需的工作量(团队速度可以有效地预测开发团队在一个Sprint中能够完成的工作量)。当然，这也会影响到开发团队在一个Sprint中能够完成多少内容。
Sprint计划会最重要的一个地方是允许用足够的时间来对Sprint Backlog进行讨论，从而达成一致。但是计划会应该是有时限的。经验法则是，一个为期两周的冲刺时间不应超过4小时，较短的冲刺时间应相应地减少。如果它需要更长的时间，那么就使用更长的时间——但是要寻找改善的机会来减少计划的时间，并相应地增加花在构建产品上的时间。
如果产品负责人没有为开发团队解释清楚PBI，团队无法将其细化成为Sprint Backlog，那么开发团队就不应该在Sprint中接受它为工作项。不明确的PBIs是工作量膨胀和Sprint失败的主要原因。Jeff Sutherland建议：一个Scrum团队可以有一个规则，如果PBIs没有得到充分的说明，那么整个团队都去海滩度假吧。(这向产品负责人发出了，关于产品待办事项列表DoR标准的清晰信息!)
Sprint计划会的一个关键输出是：开发团队应该能够解释清楚他们将如何完成当前的Sprint目标。如果他们能够解释他们的工作，这是一个好迹象，表明团队经过讨论对需求的理解已经达到到一个很好的水平，这同时也提高了团队在他们估算时间内完成工作的可能性。团队可能会认为这正是对计划会有效性的一种衡量。
如上所述，Sprint计划会产生了Sprint Backlog的初始版本。这是开发团队在Sprint中的最初计划，并在每天的每日站会中细化和调整。每日Scrum主要是一个每日重新规划的活动。
✥ ✥ ✥
Sprint计划会的质量好坏直接影响着随后每日站会活动的成功。如果Sprint目标和Sprint Backlog被很好的定义和理解，开发团队就可以有持续高效的每日站会，同时任何需要的重新计划都将是清晰的。一个糟糕的Sprint计划会可能会成为scrum团队的负担， 尤其是多团队开发场景会更突出。
Sprint计划会的主要输出是Sprint Backlog和Sprint目标。此外Sprint计划会也加强了目标的统一，它帮助开发团队和产品负责人更好地理解彼此的需求和动机。这加强了整体的信任，并让信任生根发芽。
经过团队梳理的backlog不仅是为了追求价值最大化，也增加了团队对产品的自豪感。
Picture credits: Image Provided by PresenterMedia.com.
Bruce有话说
最近在和团队一起工作的过程中，发现大家对Sprint计划会的作用不是很明确。正好翻译这篇文章描述了计划会的作用和目的。这篇文章给我带来如下几点认识：
- 启动会是PO和团队一起明确Sprint目标的时刻。这也是让团队将Sprint任务和商业价值连接起来的一个关键所在。
- 之前虽然有梳理会对PBIs进行细化和说明，不过随着时间的推移可能由于环境变化和团队经验的积累会有新的变化。启动会可以对这些内容进行调整。让PO和团队达成一致。
- PO可能会有新的PBIs加入，需要团队做评估。
- 团队确定PBIs符合DoR(Definition of Done)，并产出Sprint Backlog。以此来说明团队有信心在当此迭代完成PBIs的承诺。
- 每日站会可以根据Sprint Backlog作为依据，每天进行检视、调整持续改进当次迭代的计划,以实现Sprint目标。
- 计划会之后产出的新的调整后的Product Backlog增进了PO和团队的彼此信任，也增加了团队对产出产品的自信心和自豪感。
