速度图
Velocity 用于衡量 scrum 团队持续提供业务价值的速度，可以采用历史估算的方法，衡量一个又一个 sprint 的速度。团队通过跟踪完成达到自己团队完成标准的故事点的数量，就可以基于相对点值对未来需要完成的新的用户故事需要花费多长时间有一个比较可靠的预测。
Scrum Master 需要负责跟踪和记录速度。每次 sprint 演示会结束后，scrum master 需要计算 sprint 期间，被团队定义为完成的用户故事的预估故事点数。这一数字作为这个 sprint 的数据点被填写在速度图上。
速度图中的数值通常会呈现从高到低的趋势，因为团队会逐渐清楚他们在每个 sprint 中可以完成的工作量以及如何预估用户故事的工作量。团队磨合的时间越长，他们预估用户故事工作量的能力就越强，这让团队可以更好地预测在单个 sprint 中可以完成多少用户故事和故事点。
如果团队的构成没有变化，那么随着时间的推移，团队速率图的曲线会从非常不稳定的状态，逐渐转变为围绕一个平均值上下浮动。与其他业务图表不同的是，速度图不追求曲线的稳定攀升，而是力图实现一个相对稳定的水平值，曲线代表团队在单个 sprint 中实际可以持续完成的工作量。
提示：Velocity 是估算工具，而非 KPI。Scrum 流程外的人可能会对速度图的性质感到困惑。从管理的角度来看，希望能增加团队工作量，并寻求速度的逐渐增长。但速度图追求的是趋于稳定的平均值。你可能会听到管理层关于如何提升团队速度或追求高于常规 sprint 速度的讨论。不要被这些言论误导，并且要提醒每个人，速度跟踪的目的是为了提高团队预估他们能够持续可靠地完成多少工作的能力。如果一个速度图随着时间的推移，呈现不断攀升（或下跌）的趋势，那说明团队的估算过程存在问题。
燃尽图
燃尽图展示了团队在单个 sprint 中完成计划故事点的进度情况。燃尽图以团队计划在单个 sprint 中完成的故事点总量为起点，并跟踪团队每天完成了多少可以进行 sprint 演示的故事点。
通常，燃尽图的维护由 scrum master 负责，可能会在每天的站会后更新；或者如果团队有用来维护 scrum 板的工具的话就会自动生成并持续更新。尽管燃尽图上可能存在与 scrum 团队以外的人员相关的数据点，但其主要受众仍是团队本身。
（Worktile 迭代概览 & 燃尽图）
典型的燃尽图从左上角最高点开始，一路下降至右下角，形成一个对角线，这是 sprint 中‘最理想’的燃尽率线条。但在实际中，图表可能有别于理想的趋势。但团队只要记住任一时间节点 sprint 中剩余的工作量，以及在 sprint 某个特定时间团队需要投入多少工作量才可以达到既定开发进度。
燃尽图上的线或柱体代表该 sprint 中每天实际剩余的故事点数量。起点的线或柱体代表了团队在该 sprint 中承诺完成的故事点总量。随着工作的推进，这些柱体应该变得越来越短，直至归零。
一些团队可能选择以故事点或用户故事中的单个任务为衡量单位跟踪每日的工作量。通过燃尽图上的线或堆叠列来跟踪这些每日指标，让团队可以随时掌握整体进度情况。
原则上来说，燃尽图的线或柱体不应该呈现逐步增高的趋势。如果 sprint 结束前发现了一个 bug 或一个已经被标记为已完成 / 可演示的用户故事需要再度处理，则燃尽图当日的柱形可能高于前一天。Sprint 开始后引入新的用户故事也可能导致同样的情况。燃尽图上柱形的高度增加，表明工作范围超出了最初商定的 sprint backlog，这种做法是违反 scrum 模式的。
提示：谨防工作范围蔓延。团队的每个成员都应遵循既定的 sprint backlog 范围。如果 sprint 开始后，仍经常性地添加新用户故事，那么燃尽图中柱形反映的在 sprint 特定日期的剩余工作量可能反而会超出前一天的水平。这个柱形有时会用不同的颜色表示，以强调最初商定的 sprint 工作范围已经被拓展并导致剩余工作量的增加。如果这种情况频繁出现，那么团队就需要在 sprint 回顾会议中协商解决这个问题。
翻译 / 校对：Worktile
文章来源：Worktile 敏捷博客
欢迎访问交流更多关于技术及协作的问题。
文章转载请注明出处。