我花了5个小时以上的冲刺计划来进行为期一周的冲刺。似乎太过分了。

由于大多数团队成员都不高级，因此我们将在sprint计划中详细讨论事情。如果我们不这样做，将会在实现过程中导致错误，并在sprint过程中进行重新设计。

我们该如何处理？

我应该在计划期间讨论多少细节，以使其适合每周冲刺仅2小时的时间？

您是对的-在Sprint计划中进行5个小时的为期1周的Sprint似乎很长时间。《 Scrum指南》将Sprint Planning的时间范围设置为8个小时（1个月Sprint），并表示“对于较短的Sprint，事件通常会更短”。如果考虑该比率，一个好的目标可能是2个小时的Sprint计划（为1周的Sprint），但是没有固定的时间范围。

那么，您如何解决漫长的Sprint规划？

作为Scrum Master，我将执行以下步骤：

首先，我将与产品负责人一起确保正确订购产品积压订单。确保有效的待办事项细化和Sprint计划至关重要，以确保最重要的工作及其依赖项位于产品待办事项的顶部，以便Scrum团队可以集中精力定义，改进和准备正确的工作。

其次，我要确保团队在积压细化上花费足够的时间。《 Scrum指南》指出，提炼活动通常不超过开发团队能力的10％。例如，一个由4人组成的开发团队每周工作40个小时，应计划进行约16个小时的积压提炼。这可以单独，成组或成组完成。我发现为团队准备一个计划好的积压细化会议，然后再进行任何研究，调查或计划往往是最好的。

第三，确保团队意识到他们不需要在Sprint Planning中正确掌握所有细节。Sprint计划的目标是制定完成Sprint目标的计划。不要在Sprint计划会议上尝试进行大型设计。与合适的人一起了解不同的工作如何适应，依赖和目标，以及在Sprint计划会议之外使用时间，以进行交付工作所需的设计，实施和测试。

其中可能会有更多步骤，但这将是一个很好的起点。

我听到你了 花太久了！希望您的团队正在回顾中讨论此问题。我们尝试了几种结果不一的实验：

1. 每个人都对单张票证进行高级设计，并将其左右通过表格进行修订，然后对每张票证进行计划的小组审查。并非每个人都喜欢它，但这确实迫使我们的下辈尝试一下。团队中的某些人很乐意让其他人去思考，而他们只是遵循指示。因此，从积极的方面来说，我们的实验迫使每个人都要面对他们的知识鸿沟，这为大三学生提供了成长的挑战。从消极的一面看，并不是每个人都喜欢被当场，而且不一定会减少会议时间。下一个！

2. 尝试了配对设计。两到三个小组可以将故障单分解为任务。整个团队将审查最终的计划。它的运行速度要快得多，但有些小型吊舱的问题是一个人骑着而另一个人负责设计。

3. 跳过任务故障。我们认为我们的故事要平均，所以我们只是在浪费时间试图让整个团队参与所有事情。结果，我们的计划会议要短得多，但是设计工作是我们两人在开票时必须自己做的事情。如果大三学生正在准备机票，希望他们将需要帮助才能通过此步骤。如果尝试这样做，请在sprint中接受较少的故事，直到您对此感到满意为止。另外，请确保您的队友在不了解情况时寻求帮助是“安全的”。

最后，这取决于团队的成熟度。人们需要了解彼此的能力和偏好，并确信队友会在需要时要求输入。如果没有这些，请先修复。这样，解决会议效率低下的问题就变得容易了。

我喜欢您从@ Thomas-Owens收到的答复，但我还会再添加一项。您是否考虑过将配对编程作为敏捷实施的一部分？

结对编程将有助于（1）教您的一些初级程序员如何编写更好的代码，以及（2）结对编程中的知识，您不必总是在冲刺计划中为您布置所有的设计功能。通过一对协同工作，可以“自发地”做出一些设计决策，并增加了对编程的好处。

如果您可以帮助初级程序员更快地学习，并且知道您在Sprint Planning中未解决的设计项目将由两个人决定，那么您就没有理由不减少花费的时间。未来的冲刺计划

我不是scrum的狂热爱好者，只有大约一年的实践经验。因此，以下内容需要特别注意。

我在您写的内容中看到几个危险信号：

5小时冲刺计划

这对于一个星期的冲刺来说太长了。

冲刺计划的目标是

• 使团队知道当前的优先事项是什么，以及
• 为即将到来的冲刺制定战斗计划。

为了有效地做到这一点，双方都必须了解Product Backlog items。

为了了解Product Backlog items积压情况，必须保持良好状态。

在具体计划阶段，将Product Backlog items转换为Sprint Backlog items。

一个可能的原因是，这些项目的澄清/改进不够充分。

另一个可能的原因是，这些项目太复杂了，并留有太多解释的空间。

在冲刺计划中讨论非常详细的内容

如上所述，当项目更加具体时，讨论阶段将缩短。

另一方面：Sprint计划期望每个参与者的职业行为。这包括避免骑自行车的讨论。

也许情况很清楚，但是有人开始了一场脱胎换骨的讨论。

更多：避免讨论实现细节。尽管每个想法都在某个时间点以代码结尾，但是这不是冲刺计划讨论的重点，简单数组是否可以解决问题，还是使用链接列表会更好。

由于大多数团队成员都不高级

在Scrum中，高级和初级之间没有区别。两者都是开发人员。这是一个很好的起点，可以帮助您将讨论的重点放在一个可行的解决方案上，该解决方案应有更好的论据而不是薪水。

冲刺期间实施和重新设计的错误

需求收集中似乎存在一个基本问题，随后积压的产品非常模糊。

就像我在上面说的那样：只要状态Product Backlog良好，就很难忘记这一点。

我无法想象这样的情况：

»作为用户，我希望看到少数客户！«

“哦，您不是说我们的200万客户中的每一个都吗？”

OTOH：在这种情况下，重新设计意味着什么？如果开发人员选择了性能较慢的算法，那么下一个目标很明确：选择性能更好的算法。但这不是“重新设计”，这是一种优化。

对您的主要问题：

该如何处理？

提到这很琐碎，但无论如何我还是这样做：别忘了，你在与人打交道。

很难拥有一群能够共享共同概念的不同思想（例如在Rashomon中）。为了有效地处理此问题，请在您的通信中使用尽可能多的冗余：例如，即使每个人“都应该知道”该做什么，也要广泛解释该项目的上下文。提出问题，是否每个人都知道给定项目的主题。

如果您正在计划扑克，那么您的理解是否足够好，那就是任务的评分很低。低意味着低复杂性意味着易于理解并且不容错过。

迭代的一个副作用是，某些任务的数量会增加（因为团队已了解其功能和隐藏的复杂性）。然后就有机会将项目分解为几个较低复杂度的较低复杂度的项目。

在计划每周一次冲刺2小时的过程中，我应该讨论多少细节？

Salomonic答案：越少越好，越多越好。

tl; dr

• 选择一种简单的语言（如果有帮助，请使用简单的英语或ELI5），以避免造成误解

• 改善需求收集

• 改善积压

• 提高团队成员对个人能力以及团队能力的信心

• 避免骑车脱落

• 改善个人纪律

• 也许对每个项目使用固定的时间盒进行讨论

• 有效加强scrum master适度地位。

通过在2周的冲刺中总共进行了3个小时的梳理，我们成功地减少了计划会议的时间。我们将梳理分为四个部分。我们每周进行30分钟的修饰，每周三进行1小时的修饰。我们的冲刺活动从星期一开始，到星期五结束。结果，我们从整理会议中获得了很多有用的信息，这些信息可以作为对计划的投入，从而缩短了计划时间。我们最好的记录是一次冲刺中计划进行30分钟的会议。在大多数情况下，时间不会超过一小时到一小时零三十分钟。无论如何，还是有时间限制，但是计划是很早就完成的。