如何在 Scrum 中计算燃尽图的值

在向朋友们发布 关于燃尽图的第一篇 文章, 之后，在评论中 被问到的第二个问题是：“不清楚这些值都是怎么计算出来的”。 因此，在本文中我将尽量讲述我们是如何计算燃尽图上的每日数值的。 一如既往，如果我说错了什么，欢迎各位同事的评论，但我还是愿意相信，这个话题对我来说是足够清楚的。

让我们再回顾一下这张图表的样子。

在这个例子中考察的是一个为期 10 天的冲刺。我们可以看到已经过去了 2 天（因为 只有前 2 个分段被绿色图表填充）。

我们还可以看到总的 冲刺工作量 - 这是 一条虚线，它表明冲刺的总工作量在周一 10:00、周二 10:00 和周三 10:00 都没有变化，等于 17 SP（故事点）。

按照 Scrum 方法论， 冲刺内的工作总量在冲刺期间不会改变，因此这条线 通常 直接画满整个冲刺（全部 10 天）。它还能帮助更直观地评估还剩多少工作要做， 比在当前版本中它止于第三天要清楚得多。

实际燃尽 （绿色图表）显示实际剩余的工作。也就是说， 目前团队完成了 17 个故事点中的 1 个，这些是成功完成冲刺所必须完成的。已完成通常 被认为处于“Done”状态的任务（每个团队的 Done 是什么，由团队自己 决定。甚至有一个专门的工件，叫做 DOD - Definition Of Done - 每个 团队都有自己的定义，其中非常精确地描述了任务完成、可以将其移到 “Done”状态意味着什么。最常见的是“已部署到生产环境”，但也可能有细微差别。总之，根据当前 图表我们可以看出，只有一条团队评估为 1 SP 的故事完成了 DOD。

理想燃尽 显示在完全均匀工作的情况下，实际 燃尽图表应该处于哪个点。也就是说，目前如果工作完全均匀，应该已完成 3 SP。

我猜想，理解什么是 故事点可能会很有意思。实际上， 一个团队的 1 SP 和另一个团队的 1 SP 背后可能隐藏着 不同的工作量。例如，我们有些团队人数相同，但一个 团队的冲刺容量是 17 SP，另一个是 35 SP。这很正常。原因在于，团队自己选择 一个基准任务，并以此在梳理会上评估所有任务（过时的 名称是每周会议，PO 在会上带来用户故事进行评估，团队通过计划扑克 对其进行评估）（在 SAFe 中这是 PBR - Product Backlog Refinement）。

因此，我们可以有一个基准用户故事“我，作为汽车司机，希望在 给汽车加油后，能够在需要时获得打印在纸上的 收据”。约定它对我们团队来说是 8 SP。而当 PO 讲述一个我们需要评估的新用户故事时， 我们就相对于基准任务来评估它。相应地， 新故事可能被团队评估为 5 SP，例如等等，所有待办事项列表中的故事都会得到自己的 评估。

团队容量是根据统计数据计算的。在最初的 1-2 个冲刺中测量团队 完成的 SP 数量并计算平均值，规划就基于这个值进行（当 PO 从待办事项列表中按特定容量为冲刺挑选任务时）。

希望我已经足够清楚地描述了燃尽图上的数值是如何得出的。