题

我们的冲刺计划会议不仅不有趣，而且非常可怕。

会议很乏味、无聊，而且要花很长时间（一天，但感觉更长）。
开发商对此有所抱怨，并对即将到来的规划感到恐惧。

我们的例程非常标准（用户故事按优先级插入冲刺积压>>故事被分解为任务>>任务以小时为单位估计>>重复），我不知道我们做错了什么。

怎样才能让会议变得更加愉快呢？

...

为了响应更多信息的请求，提供更多详细信息：

为什么在冲刺开始之前未插入待办事项并确定其优先级？

用户故事确实是优先考虑的；在我们将它们分解为任务之前，我们不知道它们需要多长时间！从这里的（优秀）答案中，我发现也许我们根本不应该估计任务，而只应该估计用户故事。我们估计任务（而不是故事）的原因是因为我们对故事的估计非常错误——但我想这是一个完全不同的问题的主题。

开发商为何抱怨？

  1. 会议时间很长。

  2. 会议很单调。一个又一个的故事，一个又一个的任务，努力（是的，努力）估计需要多长时间以及涉及什么。

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

  4. 会议时间越长，房间里的焦点就越少。同事注意力越不集中，会议花费的时间就越长。递归的仇恨螺旋不断发展。我们考虑过将会议分成两天，以便让人们集中注意力，但开发人员不肯听。一天的计划已经够糟糕的了；现在我们将有 二?!

我们的部分问题是我们进入了非常小的细节（为了获得更准确的估计）。但当我们粗略估计时，我们就偏离了目标！

总结一下这个问题：

  • 我们做错了什么？

  • 还有哪些其他方法可以使会议总体上更加愉快？

有帮助吗？

解决方案

让估算变得更容易

分解你的冲刺计划。

你 需要 估计各个任务？我通过两种方式完成了冲刺计划：

  1. 故事以故事点为单位进行估算，然后任务以小时为单位进行估算
  2. 故事是按照故事点来估计的，任务只是简单地归入没有估计的情况下

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

通过这样做，您可以 减少花在冲刺计划上的时间. 。故事在冲刺计划期间得到估计，当您开始冲刺时，您可以写下您能想到的构成该故事的所有任务。显然，如果您在评估故事时遇到了一些要点，那么您可以 知道 必须在任务中处理，您可以将其添加到故事信息中并将其作为任务。

以理想单位估算

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

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

谈论故事

当你估计时， 每个人都应该对需要做什么有一个大概的了解 从开始到结束，这个故事需要什么才能完成。你不需要知道每一个细节，但足以让你认为你自己可以承担这个故事。如果您没有这种程度的信心，您可能不应该估计它。如果你说“这个故事太大了，我们无法了解大部分细节”，那么这表明这个故事太大了，应该分解。至少根据我的经验，故事足够小，如果需要的话，一个人可以单独完成它并在一两周内完成。

这也将有助于解决编辑中的第二点，即 过多的估计. 。您不必估计每个故事的每个任务，而只需估计整个故事，这应该有助于消除大量估计。至于让会议不那么单调，我建议计划玩扑克，你可以在上面看到更多关于扑克的信息。

让规划更有吸引力

使用规划扑克进行估算

就让估算变得更有趣而言， 你有没有尝试过 规划扑克? 这是我一直为多个团队的所有冲刺进行规划的方式，这是让每个人都参与的好方法，因为每个人都必须至少选择一些东西。当团队中的每个人都选择 3，而有人选择 20 并必须解释自己时，或者当团队中的每个人都选择 5 但经理选择 8（谁会与当老板想给你更多时间时！）。

去做这个， 你所需要的只是一些规划扑克牌, ，我们经常在索引卡的背面制作，或者使用普通的扑克牌，并将数值附加到面牌上。没什么特别的，它让每个人都集中注意力。请记住，尝试一整天完成任何任务（包括计划扑克）都会影响生产力。许多卡片都附有咖啡卡是有原因的。如果有人感到精疲力尽，请让团队休息一下，充电，并在每个人都精力充沛时再接起它！

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

其他提示

  1. 为什么在Sprint Taptoff之前未插入和优先考虑的Backlog项目？浪费开发人员时间并不好玩。让您的团队预先将您的团队与产品所有者和项目经理合作，以优先考虑一些产品。这适用于每个Sprint团队的规划。

  2. 为什么它需要一天才能将事物闯入任务？如果您有一个合理的团队（2-4名开发人员，则为.5-1.5 QA人，每名开发人员，1- 2个misc）然后你应该有2-4个用户故事这个sprint。使用产品所有者澄清30分钟左右，然后30分钟左右，将其拆除到〜8小时任务。 在会议期间不要进入任务。只是同意一团团队，任务足以让理智的人理解他们，谁对他们负责，以及他们应该需要多长时间。同意“他们应该需要多长时间（包括测试）”在Sprint内舒适地适合。

  3. 如果它不仅仅是将事物打破任务，你还在做什么？肯定，回顾可以花30-60分钟，但是球队进入一个凹槽时会更短。

    4. 所以总结 - 戒掉浪费人的时间，他们会少一点害怕会议。 除此之外，团队中的乐趣和comradarie不是你可以在会议中解决的东西。一起去吃午饭，笑话，混合人们才能拥有更好的个性适合，有胡子生长的比赛......一旦士气起来，人们自然会让冲刺计划会议更加壮观。

规划是Scrum的一个领域，其中团队有很多灵活性。尝试一些新的冲刺，直到你击中为你的团队工作的东西。

一些成功的想法，我要么从其他团队中审判，或者听到了其他团队：

    没有整个团队的用户故事创作和优先顺序。产品所有者和/或Scrum主人可以处理很多繁忙的工作，让团队调整它。
  • 使您的积压显着长于单个Sprint。它需要一段时间来建立它，但如果您的积压足够长，则规划会议减少到制作小调整或解决最近的业务发展。
  • 与Sprint规划分开的估算会议。如果人们认为会议太长，就没有理由不分裂它们。
  • 特别计划闯入议程。如果您经常浪费时间等待一个或两个团队成员返回，这很有用。
  • 在会议中间打破，并将每个人分配给一个或两个用户故事，然后在一起举行报告并获得共识。
  • 确保您的计划会议是关于是什么，而不是如何来做。工程师很容易进入后者。如果您需要，请设置单独的设计会议，您可以在那里讨论如何。
  • 将您的故事分开调查和实施。当团队成员对他们正在努力的事情太少时，规划会议经常会出现太长时间，并试图在会议期间弄清楚。例如，例如，您需要与您的团队没有经验的API集成。和。而不是尝试在计划会议期间创建估计和任务，而是让你无能为力的东西，让一个调查故事学习API，做一个简单的“Hello World”的应用程序，并将其教给团队。 然后您将配备实际的工作。
  • 在特定问题的会议期间跟踪。不仅仅是“规划很无聊”，而且一般的细节，“我们花了很多时间谈论不明确的要求，而且没有人似乎知道正确的答案。”然后讨论您的回顾性和头脑风暴中的那些特定问题，以获得特定的解决方案。打破你的问题，直到碎片易于解决。

我们同时举行Sprint规划和回顾性，几乎总是在90分钟内完成，但我们是较快的球队之一。我们做了一个大公司范围的长期规划，每5个冲刺需要4-6小时。当然，每个团队都不同，但如果你每天花一整天的冲刺，那么有很多改进的空间。

您的计划会话太长了！

根据我的经验，冲刺计划会议每周不超过2小时（例如，2周Sprint最多需要1/2天），但成功的应该是短于（一半）它）。

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

为我工作的方式：

  • 通过PO
    • 快速介绍冲刺
  • 估计Sprint容量
  • 故事运行和规划扑克（每故事5/10分钟），直到有足够的估计东西来覆盖Sprint
  • 团队的官方承诺/预测
然后，在我们的书桌上并行/对/自我组织，任务和任务估算。

在我之前的工作中，每个Sprint的整个第一天（我们打电话给他们迭代）被占用：

  • 回顾性。我们开始在最后一天的下午开始这样做，但我们经常发现自己回顾了Sprint，然后回去工作绑起来绑起来的冲刺的最后一个松散目的，所以我们认为在回顾之前，确保工作在我们身后会更好。它似乎良好的是整合SCRUM过程的所有会议开销，所以其他日子可以在更理想的条件下计划和花费。这通常需要2个小时。
  • sprint规划。在里程碑计划会议期间估计了积压（这可能是DEVS和POS的一整天），并且在开始之前由POS优先考虑每个Sprint。我们弄清楚了我们有多少开发者 - 日子（占假期，vaca等），抓住了我们认为我们可以脱掉堆的工作，并迅速审查用户要求（以前被我们的BAS审查）在MPM期间，获得比我们在简单的概述所需的工作的完全感。这通常需要2小时。
  • 任务规划。了解故事和验收标准，我们将每个故事分解为理想时间估计的咬尺寸任务（一个小时的花费仅仅朝着完成“完成”，没有分心或障碍）。我们的点比例最终被校准的方式，5是开发人员冲刺，所以A 1可能是一个达到的，包括两个开发人员的日子。因此，几乎所有一切都必须分解，以便团队成员能够在Scrum板上展示进展。这是另一个2小时的街区，在这个和下一个项目之间有一些给予和携带。
  • aat概述。我们的pos和bas不是程序员，没有代码。 POS隐藏在合同后，规定他们将以Word模板的形式提供要求，并将与BAS合作以在该形式中完善它们。 BAS理解代码，但他们的时间纯粹是分析和最终测试（这需要系统存在，所以他们可以将宏记录到Selenium中）。因此，要验证我们的代码是否会达到验收标准，我们必须写自己的AATS建模“论文”验收测试的行为。我们通常在我们用于单位和集成测试的同一NUnit框架中进行了这一点（我们尝试了Fitnesse并且无法快速放弃）。这是我们每个Sprint的第一天的其余部分，并继续进入第二个。

在我目前的工作中，我们仍在采用Scrum过程，我们没有团队宽的里程碑规划，并且我们在努力的许多工作没有严格的验收标准。因此，我们的Sprint规划是对每个故事所带来的和我们所说的内容的解释，因为这是一个承诺将顶级X的最佳工作占顶部的贡献。我们逃脱它 - 现在至少 - 因为我们是一支内部团队，我们每个人都与我们的软件的最终用户一起使用，以收集要求和设计解决方案。即便如此，Sprint Planning也是周一每个其他所有早晨的事情，下午都花了解任何个人障碍，以便在周二获得认真的发展。

实际上回答OP的问题而不是对比其他评论/答案表示不应该考虑这一点，有方法可以接近敏捷估计，Sprint规划和回顾，这些都比你使用的更有趣。

特别讨论您的疑虑：

  • 会议长 - 时间框。每次会议，都是追溯，冲刺规划，任务分解等，应该具有明确的目的和讨论主题，并且应该尽可能地限制为设定的时间。这是Scrum Master的工作，以保持这些会议的主题和滚动，以满足时间目标。

  • 会议是单调的 - 将有一些;你一次在一口大小的块中工作，所以你会一遍又一遍地做同样的事情。保持团队专注并驾驶实现会议的目的会有所帮助。

    我听到的是，也许你的冲刺计划会议正在努力实现太多。在我的最后一家公司，故事估计是在“里程碑规划会议”中完成的，这发生了大约四分之一季度并整天拍摄。在这些会议中，在估计的积压上建立的一切都估计在积分中。如果您正在进行故事估算，则在小时内完成任务估计，您不想同时执行它们（也许在同一天）。

  • 估计点数的故事，然后单位的任务似乎是冗余的

EM> - 他们有两种不同的目的。故事估算的目的是提供复杂性的粗略估计，您可以使用基于过去的速度和预期带宽来填充Sprint Backlog。任务估计的目的是将故事分解为占用一个开发人员日或更少的东西（因此可以分配给一个预期在时间完成的单个人），并确保您没有错误地估计了任何故事的复杂性，也不咬掉比你在冲刺中咀嚼的更多。

如果您的故事一直需要一天或更短，那么它是冗余的，但并非所有点刻度都校准平等;在我上一份工作中，5个是两个开发人员 - 周（因为在开始时我们有很多史诗来估计），这在线性比例在线刻度达到了最多2个开发人员的点。鉴于这种规模，几乎一切都应该被打破到任务。在我的新公司，一个观点更接近一个开发人员日的一半，所以一个甚至一个2个肯定是它自己的任务，3-8关于强迫团队将其分成任务的缺点。

  • 有一个恶性循环，让人们更长时间聚焦，所以需要更长的 - 时间箱。休息，就像你应该在编码时。每30分钟一次，需要5分钟伸展双腿，重组等。你可以每小时十分钟，但不要超越实体的会议时间。你的家伙可能会饥饿，或需要更多的咖啡，或卫生间休息等。不要否认他们;如果你让他们吮吸它，你会发现他们的思绪徘徊。除此之外，保持讨论简短，甜蜜，而且要帮助，如前所述。

    • Sprint计划会议有2个部分：

    1. 决定团队会做什么
    2. 决定团队如何做到。

      3. 第一部分相对直截了当 - 基于故事点的数量，团队的感觉他们可以接受，提交完成许多用户故事的优先顺序。完成。

      第二部分是开发人员实际上应该享受 - 制定故事并设计解决方案。任务脱离了这一点。因此，拥有产品所有者，或者他提供的中小企业解释了一个被选中的故事。然后有任何开发人员想要接受它，引领设计讨论。使用白板。反弹的想法。玩得开心。

      就是这样。如果设计会议并不好玩，那么就有错误的错误。

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

    分开会议。

    我们将Sprint Planning Eards分成3个单独的迷你会议

    • 积压梳理
    • 故事选择
    • 任务细分

    我们在不同的一天做每个人，在我们的每日scrum之后 - 一旦日常完成，我们就会滚入规划活动，然后我们没有（经常计划）剩下的时间。

    所以是的，我们瀑布我们的规划：-o

    我会在一秒内完成每个会话所涉及的内容，但让我解释我们如何到达这一点。

    我们，像你一样，有一个真正可怕的冲刺计划会议的问题。我们拥有所有合适的元素，但一切都刚刚拿走了，在精神上和情感上训练了。

    然后我在阅读此商业内幕关于Pivotal的5分钟每日5分钟（关于将我们的会议打破较短的会议，并在每一天开始。

    我以回顾性与团队带来了它。一些团队成员立即喜欢它，其他人有点担忧，但随后我们的实习生提到了一些学习，他读到了 Pomodoro Technice 并开始继续它，这确实有助于这个想法获得牵引力。

    所以我们决定尝试一下。
    我们将我们2小时的2小时举行到三个25分钟的课程中。 （是的，那是模糊的数学，但每个人都觉得我们的会议太长了，如果我们节省时间，只想这样做）。

    ，它的工作！ 我们已经在两个单独的项目中完成了大约6周（总共6个Sprints Total），它成为了一个不同的世界。
    我们更富有成效。 我们节省了大约一段时间。
    我们得到了更好的产出。 我们不再害怕我们的规划会议。

    老实说，我们的25分钟的时间箱很松散 - 有些会话真的很快，就像我们一些美容的一些露天会议一样快，而且我们最终识别新故事或必须在谈判期间打破故事并重新估算。总的来说，整个Shebang通常平均到不超过1.5小时，我认为这就是它适用的原因。

    到详细信息.....

    Backlog Gooming

    很简单 - 我们审查了顶级优先级故事，谈论他们所需要的东西，并确保我们的估计是好的。

    如果需要，我们会重新估算故事 - 就像我们估计了几个月前的话，在实现类似的故事后，我们可能会同意重新估算。 （我们使用更少的故事点< / a>顺便问一下，我们不要估计任务）。

    此外，如果PO添加了他的感受很高的任何新故事，这是估计它们的时间。

    因为我们不做故事选择，直到第二天，这个过程给出了一点额外的时间来做出最终判断在下次迭代中最重要的事情 - 这证明了很有帮助。

    本次会议往往与其他人和其他人一起运行。 （就个人而言，我认为这是你的PO如何做的伟大闻名指标）

    故事选择

    获取 chris voss 打开，是时候洽谈了。

    在此次会议上，我们采取了顶级优先级故事，并定义一个 dod 为每个人。我们谈判每个人都将留下和根据需要拆分和结合故事 - 直到我们都可以同意我们的冲刺目标。

    我们有利于新的心灵，并为这次会议的早安能量很好 - 并且知道我们将在另一天做任务使我们能够花费我们需要做得很好的时间并了解我们的承诺。

    任务

    好的，所以我将是第一个说，任务是我的最少的在我们旧的一天会议中规划的最不喜欢的部分。

    我们只是从不碰到我们的步伐。 我们尝试拯救任务直到会议结束 - 但我们都刚刚耗尽，那么它真的很不健康。 我们尝试在我们的谈判中与我们的国防部同时定义任务，但我们发现它太分散了分散注意力，而且太麻烦了 - 我们会在选择所有故事之前燃烧自己。此外，在估计，谈判，故事选择和任务属之间来回切换重点/思考真的很难

    上。我们挣扎着，它被吮吸了，它使我们的会议令人恐惧。

    但现在，通过在一天内定义国防部，而不是在下一步完成任务，我们不会被烧毁，我们总是在右心态，它给我们整整一天要在故事上腌，并在开始之前通过并了解所有任务。

    这个单独的imho，是一个总比赛更换器。

    将它整合在一起。

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

    • 星期一 - 每日scrum - > sprint request
    • 星期二 - 每日scrum - >积压梳理
    • 星期三 - 每日scrum - >故事选择
    • 星期四 - 每日scrum - >任务
    • 星期五 - 每日scrum - >回顾性

    它对我们来说真的很好。 如果你给它一个射击，我很想听到你的想法。

    我们每周冲刺，我们讨论了一个小时的会议，我们讨论了先前的冲刺，剩下的事情然后继续到即将到来的一周的规划。 一小时内。

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

    我只是说，如果你的团队害怕计划会议，你应该让你走一些“scrum的一些”规则“。

    这个问题已全面回答，但只需要一件事来使其工作并变得有趣。

    给团队发出权力。 - 即，让他们在他们认为是最重要的事情。

    许可以下： CC-BY-SA 和 归因
    scroll top