Sprint 计划

什么是Scrum计划（Sprint Planning）?

每个Sprint都以Sprint计划开始，Scrum团队在会上确定他们计划在Sprint期间完成什么。

在会议期间，Scrum团队专注于：

Scrum团队通过创建一个Sprint待办列表使这些规划透明化，该列表包括Sprint目标、选定的产品待办项以及开发人员交付工作的计划。

Sprint计划概览

事件	检查	适应	参与者	时间盒
Sprint计划	产品待办列表、产品目标、完成定义	Sprint待办列表、Sprint目标	Scrum团队	对于1个月的Sprint，时间盒为8小时

在事件过程中会讨论三个主题：

Sprint计划是整个Scrum团队的事件。如果认为外部人员的建议会有帮助，他们可以邀请这些人参加。团队内的成员在这个事件中有具体的职责：

产品负责人（Product Owner）

整个Scrum团队

开发人员（Developers）

Scrum Master

在Sprint计划事件中有特定的职责，帮助团队满足事件的要求。例如，如果Scrum Master发现产品待办项没有充分定义、团队没有识别潜在障碍、Sprint目标不支持产品目标或团队选择了无法实现的工作量时，Scrum Master会指导团队。
Scrum Master通常作为这个事件的主持人，但这不是必须的。Sprint计划的主持可以由事件中的任何人来完成。

Sprint计划的目的、时间盒和参与者都有明确的定义。然而，我们有时会看到Scrum团队陷入一些反模式，从而削弱了它们的价值。

参与者未正确履行其职责：

缺席的产品负责人 – 如果产品负责人或其代表不参与Sprint计划，开发人员必须介入并根据他们的理解履行产品负责人的所有职责。不幸的是，他们不太可能拥有产品负责人拥有的所有信息，这些信息使他们能够确定是什么让这个 Sprint 和每个产品待办项相对于待办列表中的其他事项更有价值。这种情况给开发人员和利益相关者带来了不必要的负担，并可能导致开发错误的产品。
产品待办项和Sprint目标由产品负责人选择，而没有关于工作价值的讨论 – 在实施一个产品待办项时，开发人员可能会做出无数决策和权衡。如果不了解他们正在创造的价值，他们很可能会做出错误的决策。
只有团队领导或信任的“核心”团队提供估算。Scrum认为团队在一起更强大，强大的估算考虑了所有团队成员的观点、知识和专长。
拉入过多的工作或由产品负责人告诉开发人员要拉入哪些工作 – 未决定Sprint期间可以完成哪些工作的开发人员未履行其职责。

待办列表或参与者未为事件做好准备：

未进行产品待办事项细化 – 没有足够的细化，开发人员会做出假设，如：每个产品待办项的价值；利益相关者的要求及其原因；产品待办项的验收标准；以及他们在一次Sprint中完成每项产品待办项的能力。这会使Sprint的成功处于危险之中。
需求模糊 – 如果产品待办项没有足够的信息让开发人员理解要求的内容，很可能他们的工作结果无法满足利益相关者的需求，浪费大家的时间。
Sprint结束时仍有未完成的工作 – 高估在Sprint期间可以完成的工作量表明产品待办项没有充分定义，团队对其能力评估不佳，或者完成定义对于产品的当前状态过于严格。
工作在此事件中被分解和估算 – 强大的Scrum团队定期细化他们的待办事项列表，包括估算和分解工作。
Sprint计划花费太长时间 – 团队越熟悉通过定期细化会议和明确定义的准备定义的待办事项列表，这些会议就越高效。长时间的Sprint计划会议通常是没有良好规划或促进的。

事件目的未实现：

错误的预测 – 开发人员被要求预测在一个Sprint中可以完成哪些工作，Scrum团队经常被要求预测产品的一部分何时可供使用。Sprint计划不佳的Scrum团队通常无法创建可靠的预测。
没有共同承诺或Sprint目标不明确 – Sprint目标旨在使团队专注于单一结果。如果团队没有致力于相同的结果，很可能Sprint目标没有明确定义。
团队更多地谈论速度而不是价值 – 速度是衡量生产了多少“东西”，不论其价值如何。Sprint的目的是创造价值，而不是执行大量的任务。
测试在Sprint结束时未完成 – 如果完成定义所需的测试在Sprint结束时未完成，工作就未完成。团队要么忽视了他们的完成定义，要么高估了他们可以执行的工作。
团队直到所有Sprint工作都定义完毕才开始处理选定的产品待办项。即使在这个事件期间/之后仍然存在未知数也是可以的，团队从已知的部分开始，并在Sprint过程中进一步定义未知部分。

打破上述反模式有助于创建强大且有效的Sprint计划事件。请考虑以下建议：