冲刺计划会议应持续多长时间？

根据您的经验，Sprint计划会议（Scrum）应该持续多长时间？8小时？还是应该缩短（简洁），并计划将更多讨论作为冲刺的一部分？我们的Sprint为期10天。

根据Scrum指南：

Sprint计划会议的时间限制为八个小时，一个月的Sprint。对于较短的Sprint，事件按比例缩短。例如，两周的Sprint有四个小时的Sprint计划会议。

这通常对我有用。

只要需要持续，就不会少也不会多。其他没有敏捷。

如果您有一个由2-3个开发人员组成的团队，并且进行1周的sprint，则超过一个小时的时间可能会适得其反。

如果您有一个由15个人组成的团队和2周的冲刺，那么您整天都在寻找东西，那么少就不够详细。

要使它最正确，需要经验，这就是回顾的目的，团队决定什么时间太长或太短。

不必担心它会变得完美或坚持某些书中所说的内容，尝试尝试并加以改进。

SCRUM与在迭代中优化过程一样，也与在迭代中优化代码一样重要。

请勿在此过程中影响您的业务。该过程支持您的业务。为自己着想而进行流程的时刻到了该获取斧头的时候了。为此，没有“正确”的方法。会议只应在您完成会议中的某件事上进行。如果您需要30分钟或4个小时，只要它可以正常工作，那就继续吧。忽略一些书/博客/教练告诉你的事情，做适合自己的事情。

只要您需要，就可以进行足够的选择，以使团队认为他们可以在sprint中达到合理的目标。但是，您应该在（上一个）sprint期间花时间来完善积压工作：估算和完善故事。

从Scrum入门（PDF）：

产品待办事项细化

Scrum中鲜为人知但有价值的准则之一是，每个Sprint的百分之五或百分之十必须由团队专用于完善（或“整理”）产品待办事项列表。这包括详细的需求分析，将大项目拆分为较小的项目，估计新项目以及重新估计现有项目。Scrum对如何完成这项工作一无所知，但一种常用的技术是在Sprint快要结束时召开专门的研讨会，以便团队和产品负责人可以专心地从事这项工作。对于一个为期两周的Sprint，持续时间的5％表示每个Sprint都有一个为期半天的产品待办事项优化研讨会。此优化活动不适用于为当前Sprint选择的项目。它用于将来的项目，最有可能在下一个或两个Sprint中使用。通过这种做法，Sprint计划变得相对简单，因为产品负责人和Scrum团队以清晰，经过充分分析和仔细评估的项目集开始计划。这次改进研讨会没有完成（或做得不好）的信号是，Sprint计划涉及重大问题，发现或混乱，并且感觉不完整。然后，计划工作通常会溢出到Sprint本身，这通常是不希望的。

这样做意味着您可以在计划过程中专注于计划，而这并不需要一整天，并且团队开始失去专注力并感到无聊。

在Scrum中，当要进行2周的冲刺时，冲刺计划的时限为4个小时，因此是半天活动。相对较长的时间的原因之一是，开发团队必须能够自信地同意将所有放入sprint积压中的项目都可以交付，这意味着他们需要了解详细信息。作为冲刺计划的一部分，团队为了在一段时间内脱离会议空间以便进一步调查项目并确保他们“准备好”进入冲刺积压工作并不少见。（可以将冲刺计划视为一个事件，而不是会议，这可能会有所帮助。）

使用您的“就绪定义”和sprint计划事件允许的时间长度，以确保进入sprint的所有积压项目都是可行且就绪的。即，它们可以在sprint中完成（完全按照“完成的定义”完成），并且有足够的信息供团队立即使用。
当然，请注意，您可能不希望在sprint计划期间对所有项目执行此操作，因为这可能会非常耗时。请尝试进行常规的积压整理（不进行冲刺计划），例如，您可以在其中分解积压的项目，并估计尚未使用计划扑克进行估计的项目。（我发现，如果您在晚餐时间有很多团队活动，可以在与开发团队共进晚餐的情况下进行此活动很有效！）

产品所有者通常可以在冲刺计划之前将高优先级项目添加到产品积压中，尽管常规上可以在冲刺计划事件之前进行积压整理，但总会有这样的新项目出现在团队需要在sprint计划活动中花费时间解决细节并估计复杂性，因此为什么它可以在10天/ 2周的sprint中延长到4个小时。

如果您需要在此事件之外进行更长的讨论，则可能在sprint待办事项列表中有一个待办事项，以“进行x的这样的讨论”，但是您应该避免包括sprint项来做您打算做的事情。确定在讨论期间完成的需求，因为这些需求尚未“准备就绪”，无法进入冲刺。

就像人们所说的那样，如果流程不能为您有效地运行，则可能有一些原因可能需要更改Scrum的运行方式。但是，Scrum是一个经过深思熟虑并经过测试的框架，因此在更改流程之前，我将确保您的推理是正确的。

在Sprint计划会议中，团队必须确定两组事情：

A）在本次Sprint期间，团队将开发什么

B）它将如何发展

该会议必须有时间限制，Sprint的每周最多两个小时，会议的每个部分（A部分和B部分）均分。

因此，对于为期4周的Sprint，此会议的时间不应超过8小时，A部分的最长会议不得超过4小时，B部分的最长不得超过4小时。

在A部分中，开发团队必须估算他们认为在此Sprint中将拥有的团队速度。他们还必须估计最优先的用户故事，并从这些（已经估计的）用户故事中选择足够的，以根据他们自己的估计团队速度来完成。

在B部分中，开发团队将讨论如何开发已经选择要开发的更具挑战性的用户故事。开发团队很可能没有足够的时间来讨论如何开发所有选定的用户案例，因此，团队必须选择最具挑战性的用户案例。

在Sprint期间，开发团队有足够的时间来完成此讨论。

根据Scrum指南：

Scrum活动

Scrum中使用规定的事件来创建规律性并最大程度地减少对Scrum中未定义的会议的需求。所有事件都是有时间限制的事件，因此每个事件都具有最大持续时间。Sprint开始后，其持续时间是固定的，不能缩短或延长。只要达到事件的目的，其余事件就可以结束，从而确保花费适当的时间而不会在过程中造成浪费。