Scrum 工件: 速度图和燃尽图

速度图

Velocity用于衡量scrum团队持续提供业务价值的速度,可以采用历史估算的方法,衡量一个又一个sprint的速度。团队通过跟踪完成达到自己团队完成标准的故事点的数量,就可以基于相对点值对未来需要完成的新的用户故事需要花费多长时间有一个比较可靠的预测。

 

image.png

 

Scrum Master需要负责跟踪和记录速度。每次sprint演示会结束后,scrum master需要计算sprint期间,被团队定义为完成的用户故事的预估故事点数。这一数字作为这个sprint的数据点被填写在速度图上。

速度图中的数值通常会呈现从高到低的趋势,因为团队会逐渐清楚他们在每个sprint中可以完成的工作量以及如何预估用户故事的工作量。团队磨合的时间越长,他们预估用户故事工作量的能力就越强,这让团队可以更好地预测在单个sprint中可以完成多少用户故事和故事点。

如果团队的构成没有变化,那么随着时间的推移,团队速率图的曲线会从非常不稳定的状态,逐渐转变为围绕一个平均值上下浮动。与其他业务图表不同的是,速度图不追求曲线的稳定攀升,而是力图实现一个相对稳定的水平值,曲线代表团队在单个sprint中实际可以持续完成的工作量。

提示:Velocity是估算工具,而非KPI。

Scrum流程外的人可能会对速度图的性质感到困惑。从管理的角度来看,希望能增加团队工作量,并寻求速度的逐渐增长。但速度图追求的是趋于稳定的平均值。你可能会听到管理层关于如何提升团队速度或追求高于常规sprint速度的讨论。不要被这些言论误导,并且要提醒每个人,速度跟踪的目的是为了提高团队预估他们能够持续可靠地完成多少工作的能力。如果一个速度图随着时间的推移,呈现不断攀升(或下跌)的趋势,那说明团队的估算过程存在问题。

燃尽图

燃尽图展示了团队在单个sprint中完成计划故事点的进度情况。燃尽图以团队计划在单个sprint中完成的故事点总量为起点,并跟踪团队每天完成了多少可以进行sprint演示的故事点。

通常, 燃尽图的维护由scrum master负责,可能会在每天的站会后更新;或者如果团队有用来维护scrum板的工具的话就会自动生成并持续更新。尽管燃尽图上可能存在与scrum团队以外的人员相关的数据点,但其主要受众仍是团队本身。

 

image.png

 

Worktile迭代概览&燃尽图

 

典型的燃尽图从左上角最高点开始,一路下降至右下角,形成一个对角线,这是sprint中‘最理想’的燃尽率线条。但在实际中,图表可能有别于理想的趋势。但团队只要记住任一时间节点sprint中剩余的工作量,以及在sprint某个特定时间团队需要投入多少工作量才可以达到既定开发进度。

燃尽图上的线或柱体代表该sprint中每天实际剩余的故事点数量。起点的线或柱体代表了团队在该sprint中承诺完成的故事点总量。随着工作的推进,这些柱体应该变得越来越短,直至归零。

一些团队可能选择以故事点或用户故事中的单个任务为衡量单位跟踪每日的工作量。通过燃尽图上的线或堆叠列来跟踪这些每日指标,让团队可以随时掌握整体进度情况。
原则上来说,燃尽图的线或柱体不应该呈现逐步增高的趋势。如果sprint结束前发现了一个bug或一个已经被标记为已完成/可演示的用户故事需要再度处理,则燃尽图当日的柱形可能高于前一天。Sprint开始后引入新的用户故事也可能导致同样的情况。燃尽图上柱形的高度增加,表明工作范围超出了最初商定的sprint backlog,这种做法是违反scrum模式的。

提示:谨防工作范围蔓延。

团队的每个成员都应遵循既定的sprint backlog范围。如果sprint开始后,仍经常性地添加新用户故事,那么燃尽图中柱形反映的在sprint特定日期的剩余工作量可能反而会超出前一天的水平。这个柱形有时会用不同的颜色表示,以强调最初商定的sprint工作范围已经被拓展并导致剩余工作量的增加。如果这种情况频繁出现,那么团队就需要在sprint回顾会议中协商解决这个问题。

 

翻译/校对:Worktile

文章来源:Worktile敏捷博客

欢迎访问交流更多关于技术及协作的问题。

文章转载请注明出处。

posted @ 2019-08-27 11:27 Worktile 阅读(...) 评论(...) 编辑 收藏