task - Scrum 燃尽图：任务还是故事？

Question

在 Scrum 中有几种方法可以做燃尽图。

有些人建议使用未完成故事的故事点作为 Scrum 中的燃尽图。

优点：只有完成的故事才能降低图表

对比：图表一开始没有向下移动，然后迅速下降

其他人建议使用剩余的任务数

Pro : 图表会向下移动，你可以看看它是否在终点线之上

反对者：你可以向下移动到最后说剩下 10 个任务（困难任务），但仍然没有完成一个故事。你失败了，因为只有完成的故事才对你的产品负责人有益。

解决方案是否同时具有未完成的故事点和未完成的任务图表？

score 7 · Accepted Answer

我们将剩余时间用于 sprint 燃尽- 团队每天都可以看到进度。如果有平坦的部分，那么它们就真的发生了。

在发布燃尽图中，我们使用了故事点。发布计划更多的是关于他的功能完整性，时间是在冲刺级别上跟踪的。产品负责人对已完成的故事感兴趣。

任务数是没用的。这个数字每天都可以改变，特别是如果你给开发者一个“自由”。他们可以在不改变总时间的情况下将任务分成更小的部分。这样的统计是没有用的。它说明了什么？它会影响 sprint 的目标吗？

score 4 · Accepted Answer

在我看来，跟踪任务是一种不太理想的跟踪方法。以我的经验，一个故事很少真的是它的任务的总和——而且通常，在实施一个故事时，我发现任务分解不是最理想的，无论如何。

而且，虽然我在评估故事时发现头脑风暴任务的价值，但我更喜欢故事足够小以至于根本没有追踪它们的冲动。事实上，为完成的任务而获得荣誉是高度误导的，因为即使完成了所有已识别任务的一半也不能保证 Sprint 将提供任何价值。这就是利益相关者最终感兴趣的：实际交付的预计价值有多少？

因此，跟踪故事并进一步分解故事既能提供更准确的反馈，又能降低无价值传递的风险。

实际上，在处理小故事时，我根本没有看到 Sprint 燃尽图有多大价值 - 只是看着卡片墙上的故事从“待做”到“进行中”再到“完成”应该给你所有您需要的信息。但是，根据我的经验，发布烧毁可能非常有价值。

score 3 · Accepted Answer

我们通常需要针对要求他们的客户的故事跟踪时间（估计与实际与估计完成）。这允许我们做一些事情：

我们还为自己的燃尽图跟踪已完成的故事，但正如已经指出的那样，这可能会导致在 sprint 开始时出现平台效应，这会告诉我们很少有用的信息（除了我们并行做得不够）。

score 2 · Accepted Answer

Burndowns（或什至“burn ups”）应该只表示剩余的工作。

如果你已经完成了一半的故事，你就不能发布它，这不算数。如果你以一个完成了一半的故事结束了春天——如果你正在测量速度，那么其中完成的任务就不算数。

只是图表故事有待完成。

这是一个更严厉的措施，但按摩数据没有用 - scrum 应该传达坏消息，以便事情得到解决。

score 0 · Accepted Answer

我们两者都做，就好像我们没有包括我们的生产线会以一种看起来什么都没有完成的方式停滞不前的任务。

如果一个故事需要 2 天才能完成，那么你有 2 天的平线，并且无法判断团队是否坐在他们的拇指上，或者工作增加了（因此任务时间增加了）。

当然，如果开发人员可以随意选择任务，则任务线可能会直线下降而不有助于完成故事，这是一种反模式。

score 0 · Accepted Answer

跟踪剩余任务的数量并不是很有帮助，因为这些任务可能具有不同的大小。

您不应该发现自己处于团队完成十个任务而没有积压项目的情况（实际上，如果您有十个开发人员，这是可能的）：每个开发人员都不应该从另一个积压项目（故事）中提取任务，直到他完成积压工作项目他所做的第一个故事也属于 - 如果另一个故事的任务比开始的sotry中的剩余任务更难，则事件。

score 0 · Accepted Answer

我用了很多“剩余时间”来进行燃尽。团队总是发现按时间跟踪燃尽与时间跟踪系统很接近，增加了管理开销，而且除非我们将人类转变为机器人，否则实际上并不准确。

我正在使用任务燃尽图（总任务、新任务、已完成任务）。好多了。确实，您看不到已完成任务或新任务的大小。但是团队每天都开会，这就是你发现问题的地方。同样，我指导团队不要创建大任务（最多 4 到 6 小时）。此外，我还添加了另一个图表，其中包含每日新任务和完成任务。团队发现任务的燃尽比使用小时更有意义。

在团队了解了在任务中分解故事的价值后，我想尝试按故事进行燃尽。因此，拥有最多 5 或 8 个故事点的小故事。来自 Jeff Sutherland 的博客，这是让团队取得高绩效的一大步。

另外，我想提一下，燃尽图只是“一目了然的进步表现”。与团队和 PO 最重要甚至更相关的是：每天提到的关于任务的内容 + 故事进度百分比 + 障碍列表。一段时间后，管理层和团队成员不再关心燃尽（或燃尽）。

score -1 · Accepted Answer

我们使用任务是因为它提供了更多的粒度。仅绘制故事的完成情况（我们每两周 sprint 绘制 5-10 个）只会显示每一两天的变化，并且正如您所提到的，在 sprint 开始时根本不会有太大变化。

我的团队发现的另一件有用的事情是使用堆叠折线图，其中“待办事项”、“进行中”、“准备 QA”和“已验证”各有一条线。这样，很容易看到创建备份的过程中的任何阶段。

score -1 · Accepted Answer

使用剩余时间用于 Sprint 燃尽 - 在 sprint 计划期间，根据您对完成的定义估计完成故事的所有工作 - 每天，开发人员和测试人员重新估计他们所有工作的剩余时间（向上或向下变化） - 跟踪通过剩余小时数的冲刺燃尽 - 一个冲刺进展好坏的重要指标

这不适用于发布燃尽图，因为您不会分解待办事项中的所有故事，而只会分解 sprint 计划研讨会中下一个 sprint 的故事。因此，请使用故事点燃尽图（整个团队在规划扑克会议期间得出的相对规模和复杂性值）。这是您发布进度的重要指标。

9 回答 9