Scrum Burndown问题

Question

我们已经使用Scrum大约9个月了，它已经基本上成功了。然而，我们的燃尽图很少看起来像“模型”图表，而是更像是一个可怕的过山车，有些呕吐物会引起攀爬和跌落。

为了尝试和解决这个问题，我们在sprint原型设计和设计之前花费了更多的时间，但是我们似乎仍然在sprint中发现了比最初想象的更多的工作。注意：我的意思是说，遇到积压所需的工作比最初的想法更为复杂，而不是我们为积压确定了新项目。

这是Scrum的常见问题，是否有人有任何提示可以帮助您顺利驾驶？

我应该指出，我们的大多数开发工作都不是绿地，因此我们在现有的大型复杂应用程序中维护功能。 scrum是否不适合这种类型的开发只是因为你不知道现有代码会引起什么问题？

在sprint开始计算开发细节之前，我们应该花多少时间？

更新：我们现在取得了更大的成功和更顺畅的旅程。这很大程度上是因为我们在估算时采取了更为悲观的观点，即当他们不去计划时，这给了我们更多的喘息空间来处理事情。你可以说它让我们变得更加“敏捷”。我们也试图改变这样的看法，即烧毁图表是某种时间表而不是范围v资源的指示。

Answer 1

有关平滑事物的一些提示。

1）正如其他人所说的那样 - 尝试将任务分解成更小的块。更明显的方法是尝试更详细地分解技术任务。在可能的情况下，我鼓励您与产品所有者交谈，看看您是否可以缩小范围或“减薄”故事。我发现后者更有效。如果团队和产品所有者都了解正在讨论的内容，则更容易处理优先事项和估算。

我的一般经验法则是任何估计大于理想日的一半可能是错误的： - ）

2）尝试做更短的冲刺。如果你正在做一个月的短跑 - 试试两周。如果你做了两个星期 - 试试一个。

• 它限制了故事大小 - 鼓励产品所有者和团队处理更容易准确估计的小故事
• 您可以更频繁地获得有关估算的反馈 - 并且更容易看到您在冲刺开始时做出的决定与实际发生的事情之间的联系
• 练习一切都会好转： - ）

3）使用站立和回顾来更多地了解起伏的原因。是时候花时间在代码库的特定区域？是民间误解产品所有者造成的吗？随机紧急情况会使开发时间远离团队？一旦你有了更多了解起伏起伏的地方，你就可以经常解决这些问题。再次 - 较短的冲刺可以帮助使这更明显。

4）相信你的历史。你可能知道这一个......不管怎样我会说:-)如果摆弄那个可怕的遗产Foo包比你认为它会持续冲刺长3倍 - 那么只要你认为它也需要3倍下一个冲刺。无论你认为这次会有多么有效;-)相信历史，并使用昨天的天气来指导你在明年春天的估计。

希望这有帮助！

Answer 2

我很高兴听到scrum在很大程度上取得了成功 - 这比sprint burndown图表看起来更理想更重要。 sprint burndown只是团队的一个工具，可以帮助它了解冲刺目标是否正常。如果球队一直在满足冲刺目标，我不会太担心图表看起来像过山车。一些建议

• 在sprint回顾期间，向团队询问其他工作的来源
• 额外的工作可能来自sprint早期没有良好的验收测试
• 额外的工作可能来自没有整齐的积压。一个好的经验法则是花费至少5％的团队时间来提前考虑下一个sprint的故事。
• 监控正在进行的工作 - 团队并行做得太多了吗？
• 在sprint计划期间 - 团队如何看待构成故事的任务细分？

如果您还没有达到冲刺目标 - 使用已建立的团队速度在下一个冲刺期间减少。你必须先行走才能跑步。

Answer 3

根据我的经验，Scrum肯定更倾向于新开发而不是维护。新开发比维护旧的大型代码库更容易预测。

话虽如此，一个可能的问题是你没有将任务分解成足够小的块。人们对软件规划的普遍问题在于，他们认为“哦，这项任务应该花费我2天时间”，而不是真正考虑做这项任务的内容。通常情况下，你会发现，如果你坐下来考虑这个任务包括做A，B，C和D，并结束超过2天的工作。

Answer 4

正如其他人所说，我希望燃烧可以上下起伏。事情发生了！您应该使用“向上和向下”位作为回顾的素材。

确保每个人都清楚“正在做什么”的含义，并使用这种共同理解来帮助推动您的计划会议。通常会列出可用的内容列表（a）可以帮助您记住可能会忘记的内容，（b）可能会触发更多有关任务的想法，否则这些任务会在以后出现。

要考虑的另一点 - 如果你每个月都有一个不可预测的代码库工作，我仍然希望你的速度正常化到一个相当稳定的速度。只需跟踪您计划工作的成功情况，并在计划时仅使用已完成的项目。然后专注于您的计划外任务，看看是否有任何模式表明您可以采取不同的方式将这些内容包含在计划的工作中。

Answer 5

我遇到过类似的问题。我以前的团队（在一年多的时间里）很大，我们为一系列初始产品发布维护了一个非常庞大，快速变化的代码库。我们的burndowns看起来很可耻，但这是我们做过的最好的事情。

有一件事可能有所帮助（让你的图表看起来更好）是坚持承诺不变的小时数/分数。如果你低估了一项任务，并且必须加倍工作时间，那就从sprint中抽出一些东西。如果你执行一项新任务，那么它显然比你的团队承诺的优先级要高，以便将其他事情拉出来。

我们尝试在规划之前和之前将任务分解为许多任务，这似乎从来没有帮助过。事实上，它只是给了我们更多的门票，以便在冲刺期间跟踪。要求开始转移到门票，并且（毫不奇怪）在所有洗牌中丢失。

在我的新团队中，我们采取了一种非常激进的方法，并开始制作大票（有些长达一周以上），其中包括“在ProjectX中实现v1.2功能”。 ProjectX（包括版本1.2）的要求/功能列表保存在维基上，因此票证非常干净，只跟踪执行的工作。这对我们有很大帮助 - 我们方式更少的门票可以跟踪，并且能够完成所有冲刺，即使我们不断完成我们的冲刺任务以帮助其他团队或推出火灾。

如果（并且仅当）我们被迫（由男方）引进新物品，我们继续将物品推出冲刺。

另一个帮助我们的简单提示：将“冲刺总时数”添加到您的燃尽状态。这应该是所有估计的总和。努力保持这条线不变可能有所帮助，并提高你的团队可能遇到的问题的可见性（假设这不会让你降级......）

-ab

Answer 6

我的burndown也有类似的问题。我通过改进燃尽中包含的内容来“修复”它。

SiKeep评论道：

  

它对积压的进展   选择用于该sprint，可能或   可能不会最终释放。

既然您为sprint选择了某些东西，那就是燃尽的东西，我不知道所有的“新作品”应该出现在燃尽状态。我会看到它进入积压（不影响燃尽），除非它足够重要进入你当前的冲刺（这将在燃尽中显示为上升趋势）。

如果趋势线基本上遵循预期的速度，那么轻微上升和下降是正常的。我会担心你提到的过山车趋势。然而，通过仅向当前冲刺添加高优先级项目来隔离燃尽的想法可能有助于抑制你的燃尽时的这些起伏。

正如其他人所说，冲刺开始前的计划应该很短......（no more than 4 hours）。

Answer 7

我们正在为计划外任务使用“时间框”任务。每当高优先级的工作即将到来，或者突然出现突发错误时，我们就可以使用时间盒的时间（但是，我们永远不会低于零）。 这种方法的另一个优点是我们可以轻松跟踪哪些任务无法预料，并在下一次sprint计划中考虑这些因素。

Answer 8

您可以在sprint的开始日期集成新作品，以获得漂亮的Burndown图表。

您可以使用特定标记标记其他工作，并在sprint结束时评估为什么您之前无法识别这些任务。

Answer 9

我们现在正在使用刻录图表。我们不仅仅绘制剩下的工作量，而是绘制两件事：完成的工作量和工作总量（即已完成+未完成）。

这会在图表上为您提供两行，以便在完成所有工作后满足。它还有一个很大的优势，因为它可以清楚地显示进度是否缓慢，因为已经添加了更多的工作。

如果您愿意，PO'拥有'一行（总工作），开发人员/测试人员'拥有'另一行（完成工作）。

PO的行会在添加/删除工作时上下移动。

dev / tester系列只会在完成工作时上升。

Answer 10

文章Is it your burn down chart?解释了刻录图表中给定状态的含义。它还提供了有关如何处理的建议。

文章中描述的一些例子：

Answer 11

这是应该的。如果您的燃尽图表看起来像模型图表，那么您就遇到了麻烦。该图表将有助于了解您是否能够做出承诺并完成所有故事。

在冲刺期间发现故事总是会发生。理想情况下，您可以预先设计并找出任务，但如果它们有效，为什么大型的前期设计不起作用？ 为了回答您的上一个问题，sprint计划应该采用at most four hours。