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