我们的Sprint计划会议不仅不好玩，而且简直令人恐惧。

这些会议既乏味又无聊，而且要花很多时间（一天，但感觉要更长一些）。
开发人员对此表示抱怨，并担心即将到来的计划。

我们的例程非常标准（按优先级将用户故事插入到sprint待办事项中>>将故事分解为任务>>按小时数估算任务>>重复），我无法弄清楚我们在做什么错。

我们如何使会议变得更加愉快？

...

应要求提供更多信息的更多详细信息：

为什么在sprint启动之前未插入待办事项并按优先级排序？

用户故事确实是优先的；我们不知道他们会花多长时间，直到将他们分解成任务！从这里的（优秀）答案中，我看到也许我们根本不应该估计任务，而应该仅估计用户故事。我们估计任务（而不是故事）的原因是因为我们一直在错误地估计故事，但我想这是一个完全不同的问题。

开发人员为何抱怨？

1. 会议很长。

2. 会议是单调的。一个接一个的故事，一个接一个的任务，奋斗（是的，奋斗）来估计需要多长时间和涉及什么。

3. 估计任务使用户故事的估计显得毫无意义。

4. 会议时间越长，会议室的焦点就越少。同事注意力越集中，会议花费的时间就越长。递归的仇恨螺旋发展。我们已经考虑将会议分成两天，以使人们集中注意力，但是开发人员对此一无所知。一天的计划已经够糟糕了；现在我们有两个？

问题的一部分是我们进入了非常小的细节（以便获得更准确的估计）。但是，当我们粗略估算时，我们远远超出了预期！

总结一下问题：

• 我们做错了什么？

• 还有什么其他方法可以使会议更加愉快？

简化估算

分解您的冲刺计划。

您是否需要估算各个任务？我已经完成了两种方法的冲刺计划：

1. 故事以故事点为单位进行估算，然后任务以小时为单位进行估算
2. 故事是根据故事点进行估算的，而任务只是在其中进行评估，而没有任何估算

在这两者中，我更喜欢第二种选择。我发现不估计任务可以使开发人员有更大的自由来应对变化。如果某项任务不再有意义（您发现某项任务不适用或已在上一个冲刺中完成了多少次），则可以将其丢弃而不会受到任何惩罚，或者您可能需要将当前任务更改为一些新的东西，可能会分解。如果您同时估计这两者，那么您实际上是多余的，因为任务的总和应该代表故事的要点，反之亦然。除了知道各个任务将花费多少时间之外，您还能从中真正获得什么价值？如果您发现自己的任务规模确实差异很大，可以发挥作用，那么我建议将这些任务分解为更小，更均匀的块。

这样，您可以减少花在冲刺计划上的时间。在sprint计划期间会估算故事，当您开始sprint时，您可以放下所有可以想到的组成该故事的任务。显然，如果有，你估计，你的故事，遇到点知道将有一个任务要处理，你可以添加到这个故事的信息，并把它作为任务。

以理想单位估算

故事点应该以理想的单位显示，例如理想的工时或理想的工作日。这意味着在给定完美的一天，没有中断，没有会议，一切都按计划进行的情况下，您可以在X天内完成任务。现在，每个人都知道这根本不是事实，但是统计数据的奇妙之处在于它不一定必须如此。

我的意思是，在理想的情况下估计了一段时间之后，您意识到，完成一个故事可能平均需要25％的时间。假设您估计了4个理想的工作日，而您却花了5个工作日。随着时间的推移，您会对此进行跟踪，然后大致了解了从理想的工作日转换为实际的工作日的情况。您的第一个直觉是尝试通过高估来弥补这一点，您可能是错误的。这里最主要的是保持一致。这样，您的长期平均值保持不变。当然，有时会落空，有时会结束，但是您估计的越多，您的生活就会越好。如果发现你仍然 无法得到一个体面的估计，也许这意味着您对故事了解不足，无法正确估计它。

谈论故事

当您估计时，每个人都应该大致了解从头到尾需要完成的工作，以及完成该故事所需要的工作。您不需要知道每个细节，但足以让您自己承担这个故事。如果您没有那样的信心，那么您可能不应该对此进行估计。如果您说“这个故事太大了，以至于我们无法了解大多数细节”，则表明该故事太大了，应该将其分解。至少从我的经验来看，故事足够小，这样一个人（如果需要）可以独自进行研究，并在一两周内完成。

这也将有助于解决您在编辑中的第二点，即估计过多。您无需估计每个故事的每个任务，而只需估计整个故事，这将有助于消除很多估计。至于减少会议的单调性，我建议您规划扑克，您可以在上面看到更多信息。

使计划更具吸引力

使用规划扑克进行估算

至于使估算更加有趣，您是否尝试过计划扑克？这是我一直计划在多个团队中进行所有冲刺的方式，也是让每个人都参与其中的好方法，因为每个人都必须至少选择一些东西。当团队中的每个人都选3个，有人放下20个并要自我解释时，或者团队中的每个人放下5个但经理放下8个时，也会有很多有趣的事情（谁会与之争辩）老板想给你更多时间！）。

为此，您只需要准备一些规划的扑克牌，我们通常在索引卡的背面制作这些扑克牌，或者使用具有附加值的普通纸牌。没什么花哨的，它使每个人都专注。只需记住，尝试一整天完成任何任务（包括计划扑克）都会对生产力造成损害。有许多套卡附带咖啡卡，这是有原因的。如果有人感到筋疲力尽，请给团队休息一下，让他们充电，然后在每个人都新鲜的时候捡起来！

作为物理卡的替代方法，您还可以查看电子卡。真正的好处是自动跟踪结果，跟踪要估计的用户故事并允许每个人一次显示他们的卡，以避免“作弊”（一个人的估计由于能够看到他们的卡而受到另一个人的影响）。显然，这需要每个人都拥有一台计算机，并且能够专注于手头的任务，因此请自行决定使用它。

1. 为什么在sprint启动之前未插入待办事项并按优先级排序？浪费开发人员的时间并不有趣。让您的团队提前几天与产品负责人和项目经理进行合作，以优先考虑事项。这也适用于计划每个冲刺团队中的人员。

2. 为什么要花一天的时间将事情分解为任务？如果您的团队规模合理（2-4个开发人员，每个开发人员0.5-1.5个QA人员，1-2个杂项），则此sprint应该有2-4个用户案例。与产品负责人一起澄清要求，花费30分钟左右，然后将其花30分钟左右的时间进行约8小时的工作。在会议期间不要输入任务。只要团队一致同意，什么任务足以使理智的人们理解它们，对它们负责的人以及应该花多长时间。同意“他们应该花多长时间（包括测试）”适合冲刺。

3. 如果不仅仅是将事情分解为任务，您还在做什么？当然，回顾可能需要30至60分钟，但随着团队的参与，回顾会更短。

因此，总而言之-避免浪费人们的时间，他们对会议的恐惧会更少。除此之外，您无法在会议中讨论团队中的乐趣和同志心。一起去吃午饭，开个玩笑，聚在一起，使人变得更适合个性，举办更多的胡须竞赛……一旦士气高涨，人们自然就会使冲刺计划会议变得更加轻松。

计划是团队具有很大灵活性的争执领域之一。尝试每个冲刺的新事物，直到找到适合您团队的事物。

我亲自尝试过或从其他团队那里听说过的一些成功想法：

• 在没有整个团队的情况下进行用户故事的创建和优先级划分。产品负责人和/或Scrum主管可以处理很多繁忙的工作，而只需让团队对其进行调整即可。
• 使您的积压工作明显长于单个冲刺。建立起来可能要花一些时间，但是如果您的积压时间足够长，那么计划会议就可以减少进行一些小的调整或解决最近的业务发展。
• 将评估会议与冲刺计划分开进行。如果人们认为会议时间太长，则没有理由不拆分会议。
• 计划特别列入议程。如果您经常浪费时间等待一两个团队成员返回，这很有用。
• 在会议中休息，分配每个人分配一个或两个用户故事的任务，然后聚在一起开会报告并取得共识。
• 确保您的计划会议是关于做什么而不是如何做。工程师很容易陷入后者。如果需要，可以召开单独的设计会议，讨论如何进行。
• 将您的故事分为调查和实施。当团队成员对他们将要从事的工作了解得很少，并试图在会议期间弄清楚时，计划会议通常会花费太长时间。
  例如，假设您需要与您的团队没有经验的API集成。不要在计划会议上尝试为您无知的事情创建估算和任务，而是编写一个调查故事来学习API，创建一个简单的“ hello world”应用程序，并将其教给团队。 然后，您将有能力计划实际的工作。
• 在会议期间跟踪特定问题。不仅“计划很无聊”，而且还包括诸如“我们花大量时间谈论不清楚的需求，而且似乎没人知道正确的答案”这样的细节。然后在回顾中讨论这些特定问题，并为特定解决方案集思广益。分解您的问题，直到容易解决为止。

我们同时进行冲刺计划和回顾，并且几乎总是在90分钟内完成，但是我们是速度更快的团队之一。我们每5个Sprint进行一次大公司范围的长期计划，这需要4-6个小时。当然，每个团队都是不同的，但是如果您每个冲刺都花一整天，那么还有很大的改进空间。

您的计划会议时间太长！

根据我的经验，一个Sprint计划会议的每周计划召开时间不应超过2个小时（例如，一个2周的Sprint计划最多应花费1/2天），但是成功的会议应该短于此时间（一半）。

在您的特定情况下：为什么要估算任务？您应该在计划期间仅估算故事。特定任务所有者可以稍后估计任务。

一种对我有用的方法：

• PO快速介绍冲刺
• 冲刺能力的估计
• 故事逐渐消失，并计划扑克（每个故事的时长为5/10分钟），直到有足够的估计资料来覆盖冲刺为止
• 团队的官方承诺/预测

然后，在我们的服务台上以并行/对/自组织方式进行任务分配和任务估计。

在我上一份工作中，每个sprint的第一天（在那儿我们称之为迭代）都花了：

• 回顾性的。我们从最后一天的下午开始执行此操作，但是我们经常发现自己正在回顾该sprint，然后回去工作，以捆绑该sprint工作的最后松散的末端，因此我们认为最好确保在回顾之前，工作全在我们身后。合并Scrum流程的所有会议开销似乎是合乎逻辑的，以便可以以更理想的方式计划和花费其他日子。这通常需要2个小时。
• 冲刺计划。积压工作是在里程碑计划会议（对于开发人员和PO而言，可能是一整天的时间）内进行估算的，并且在每次冲刺开始之前，PO会对其进行优先级排序。我们计算出有多少开发人员工作日（考虑假期，假期等），抓紧了我们认为可以做的工作，并迅速查看了用户需求（之前由我们的BA审核）与我们在MPM期间进行的简单概述相比，可以更全面地了解工作需要做什么。这通常需要另外2个小时。
• 任务计划。知道了故事和接受标准后，我们​​将每个故事分解成在理想小时内估计的小规模任务（花费一个小时专门用于“完成”该任务，而没有干扰或阻碍）。我们的点数刻度最终被校准的方式，一个5是开发者冲刺，因此1可以是任何东西，包括两个开发者工作日。因此，几乎所有内容都必须分解，以使团队成员能够在Scrum板上显示进度。这是另一个2小时的程序块，在此与下一个项目之间需要一些让步。
• AAT概述。我们的PO和BA不是程序员，也没有代码。这些PO隐藏在合同中，该PO规定它们将以Word模板的形式交付需求，并将与BA一起以这种形式完善需求。BA理解代码，但是他们的时间纯粹是分析和最终测试（这需要系统存在，因此他们可以将宏记录到Selenium中）。因此，要验证我们的代码是否符合验收标准，我们必须编写自己的AAT，以对“纸质”验收测试的行为进行建模。通常，我们在用于单元和集成测试的NUnit框架中执行此操作（我们尝试过FitNesse，但不能足够快地放弃它）。这是我们每个冲刺第一天的剩余时间，并一直持续到第二天。

在我目前的工作中，我们仍在采用Scrum流程，我们没有团队范围内的里程碑计划，而且我们正在从事的许多工作都没有严格的接受标准。因此，我们的冲刺计划不仅是对每个故事的涵义和我们将要完成的事情的解释，而且是对使最高X理想工作时间减至最高的承诺。我们至少在目前为止无法使用它，因为我们是一个内部团队，我们每个人都与软件的最终用户亲自合作来收集需求和设计解决方案。即使这样，每隔一个星期一，冲刺计划就成为一个刻不容缓的事情，而下午则花了很多时间清除个人障碍，以便能够在周二认真开始开发。

要实际回答OP的问题，而不是与其他评论/答案说不应该花那么长时间进行对比，可以采用一些方法进行敏捷估计，冲刺计划和回顾，这些方法可能比您使用的要有趣。

具体解决您的问题：

• 会议时间很长 -请在会议中设定时间。每次会议，无论是回顾会议，冲刺计划，任务分解等，都应有明确的目的和讨论主题，并应尽可能地限制在一定的时间范围内。Scrum Master的职责是保持这些会议的主题并不断进行以实现时间目标。

• 会议是单调的 -其中会有一些。您正在一次一小块地工作，一次又一次地做同样的事情。保持团队专注并推动实现会议目的将有所帮助。

  我听到的另一件事是，也许您的sprint计划会议正在努力完成太多事情。在我的上一家公司中，故事评估是在“里程碑计划会议”上进行的，该会议大约每季度一次，耗时一整天。在那些会议中，所有我们未估计的积压工作都以点数进行了估计。如果您要以点为单位进行故事评估，然后以小时为单位进行任务评估，则您不希望同时（可能是在同一天）同时进行这两种评估。

• 以点为单位评估故事，然后以小时为单位进行任务似乎是多余的 -它们有两个不同的目的。故事估算的目的是提供复杂度的粗略估算，您可以根据过去的速度和预期的带宽来填充冲刺积压。任务估计的目的是将故事分解成一个开发人员一天或更短的时间（因此可以分配给一个预期会及时完成的​​工作），并确保您没有错误估计了任何故事的复杂性，也没有超出您在冲刺中所能咀嚼的范围。

  如果您的故事全部花费一天或更短的时间，那么这是多余的，但并非所有分数标度都得到了相同的校准；在我的上一份工作中，有5个开发人员工作了两个星期（因为一开始我们需要估计很多史诗），在线性范围内得出的结果最多等于2个开发人员工作日。考虑到这种规模，几乎所有内容都应分解为任务。在我的新公司中，开发人员一天的工作时间接近一半，因此1甚至2绝对是它自己的任务，而3-8则很难迫使团队将其拆分为任务。

• 有一个恶性循环，那就是花更长的时间使人们的注意力减少，所以也需要更长的时间-将时间框定为时间框。休息一下，就像编码时应该休息一样。每隔30分钟，请花费5分钟来伸展腿，重新组合等。您可以每小时使它达到十分钟，但不要将会议时间推得太远。你们可能会饿了，或者需要更多的咖啡，或者需要上洗手间等。如果让他们吸吮，就会发现他们的思想在流浪。除此之外，如前所述，保持简短，甜蜜和切题的讨论也将有所帮助。

Sprint计划会议分为两部分：

1. 决定团队将做什么
2. 决定团队的工作方式。

第一部分是相对简单的-基于团队认为可以承担的故事点数，并致力于按照优先级顺序完成许多用户故事。做完了

第二部分是开发人员真正应该享受的东西-详细讲故事并设计解决方案。任务不在那了。因此，请产品所有者或他提供的任何SME解释一个选定的故事。然后由任何开发人员想要承担它，领导设计讨论。使用白板。反弹想法。玩得开心。

就是这样。如果设计会议不好玩，那肯定是有明显的错误。

是的，我知道这是一个老问题，但是我有一个新答案。：P

拆分会议。

我们将Sprint计划会议分为3个单独的小型会议

• 积压整理
• 故事选择
• 任务分解

我们会在每天的Scrum之后的不同一天做每件事-每天完成之后，我们会立即进入计划活动，然后在一天的其余时间中没有（常规的）会议。

所以，是的，我们瀑布了计划：-O

我将在一秒钟内详细介绍每个会话中涉及的内容，但让我解释一下我们是如何实现的。

我们和您一样，对于真正令人恐惧的Sprint计划会议有问题。我们拥有所有正确的元素，但是一切都花了很长时间，并且真的在精神和情感上竭尽全力才能通过。

然后，在阅读了这份Business Insider文章（有关Pivotal每天5分钟的时间）后，我得到了这个想法，该文章涉及将我们的会议分成更短的会议，并在每天开始时进行。

我回顾了整个团队。一些团队成员立即喜欢它，另一些则有些担心，但是随后我们的实习生提到了他读过的关于番茄技术的一项研究，并开始进行这项研究，这确实帮助了这个想法。

因此，我们决定尝试一下。
我们将2小时的会议分成了三个25分钟的会议。（是的，这是模糊的数学，但是每个人都觉得我们的会议太长了，只有在节省时间的情况下才想这样做）。

而且有效！现在，我们已经在两个独立的项目上进行了大约6周的工作（总共6个为期两周的sprint），它的存在与众不同。
我们生产力更高。我们节省了大量时间。
我们获得更好的输出。而且我们不再害怕我们的计划会议。

老实说，我们25分钟的时间安排太宽松了-有些会议进行得非常快，例如在某些梳理会议中需要5-10分钟，而有些则很长，例如当我们最终发现新故事或不得不分拆故事时并在协商过程中重新估算。总体来说，整个shebang平均不超过1.5个小时，我认为这就是为什么效果如此之好的原因。

到细节.....

积压整理

非常简单-我们回顾最重要的故事，讨论它们所包含的内容，并确保我们的估算正确。

如果需要，我们将重新评估故事-比如说几个月前我们估算了一些事情，并且在意识到类似故事的实际发生后，我们可能会同意重新评估。（顺便说一下，我们使用无单元的故事点，并且我们不估算任务）。

另外，如果采购订单添加了他认为是高优先级的任何新故事，那么现在是评估它们的时候了。

因为我们要到第二天才进行故事选择，所以此过程使采购订单有更多的时间来做出最终判断，以决定下一次迭代中最重要的事情-这被证明是非常有用的。

与某些采购员的会议往往会很短，而与其他采购员的会议往往会很长。（个人而言，我认为这是您的PO运转情况的绝佳指示器）

故事选择

让您的Chris Voss上手，现在该进行谈判了。

在本次会议上，我们以头等大事为重点，并为每个案例定义了一个国防部。我们会协商各自的含义-根据需要拆分和合并故事-直到我们都同意我们的Sprint目标为止。

有了新的想法和早上的精力来参加会议，我们会受益匪浅-而且知道我们第二天会做任务，这使我们可以花时间真正进行妥善谈判和理解我们的承诺。

任务

好的，所以我将是第一个说，在过去的一天会议中，任务是我最不喜欢进行计划的一部分。

我们从来没有做到这一点。在会议结束之前，我们一直尝试保存任务-但那时我们都精疲力尽，这真的没有效果。在协商过程中，我们尝试与国防部同时定义任务，但是我们发现它太分散注意力和麻烦了-在选择所有故事之前，我们会精疲力尽。另外，真的很难在估计，谈判，故事选择和任务生成之间来回切换焦点/思考。我们苦苦挣扎，很糟糕，这使我们的会议糟透了。

但是现在，通过在一天中定义DoD，直到第二天才执行任务，我们才不会精疲力尽，我们始终处于正确的思维状态，这使我们整整一天都可以沉浸在故事中，在开始之前，请仔细考虑并理解所有任务。

恕我直言，仅此一项就能彻底改变游戏规则。

全部放在一起。

因此，这是我们的Sprint仪式时间表现在的样子：

• 星期一-每日Scrum-> Sprint评论
• 星期二-每日Scrum->待办事项梳理
• 星期三-每日讨论->故事选择
• 星期四-每日Scrum->任务
• 星期五-每日Scrum->回顾

对我们来说真的很好。如果您试一试，我很想听听您的想法。

我们每周进行一次冲刺，并进行一个小时的会议，讨论上一次冲刺，剩下要做的事情，然后进行下周的计划。一小时之内。

这当然是因为我们发现，在我们的案例中，严格遵循Scrum只会浪费太多时间。这是因为当请求者创建用户故事时，大多数故事已经与我们的团队成员进行了讨论。

我只是说，如果您的团队讨厌计划会议，那么您可能应该放开一些混乱的“规则”。

这个问题已经得到了全面的回答，但是只需要一件事就可以使其工作并变得有趣。

赋予团队力量。-即让他们从事他们认为最重要的事情。