关于影响价值交付效率的因素，我们可以就如下方面进行分析。

1.速率

速率指的是团队对一个Sprint里完成的工作的度量，单位可以是用户故事的点数、理想人天，或者是用户故事的数量。一个Sprint结束的时候，团队应该统计实际完成的速率与计划的速率之间的比值，并且对没完成的用户故事做回顾，看看需要采取什么改进措施。

一般来说，速率的统计用柱状图表示，如图9-4所示。

图9-4速率统计示意图

资料来源：电子工具JIRASoftware绘制的速率统计图

图9-4中“已承诺”所代表的柱状图是每个Sprint承诺的速率，“已完成”所代表的柱状图是每个Sprint实际完成的速率。每个Sprint实际完成的速率可作为后续Sprint计划的参考。

速率的统计不一定需要电子工具，手工绘制、Excel都可以。

某Scrum团队连续四个Sprint的实际速率与计划速率的对比如表9-2所示。

表9-2速率示例

该团队的计划有很大的问题：连续三个Sprint都没有完成计划的Backlog，而且每个Sprint的实际速率与计划速率相差很大；经计算得出，连续三个Sprint的实际平均速率是32个故事点，在这样的速率下，却计划在第四个Sprint完成92个故事点。当时，我问这个团队做出这样的计划是怎么考虑的？团队的回答是：“计划只是个计划，我们就是要制订一个非常有挑战的计划，完不成没关系。”对此，我认为这样的团队长此以往下去，会逐渐失去与产品负责人彼此之间的信任。

2.Sprint燃尽图

燃尽图的全称是“总剩余工时的燃尽图”，指的是当前Sprint计划的用户故事被拆分的所有任务，其剩余估算时间总和随着日期的变化而逐日递减的统计图，如图9-5所示。

例如，在Sprint计划会议结束后，团队统计出所有计划的用户故事被拆分成的任务，其估算时间之和为50个小时，于是初始点被打在横坐标0、纵坐标50的位置上。由初始点和Sprint的最后一天所连成的线是理想燃尽线，即如果团队每天匀速完成等量时间的任务，那么就应该在Sprint的最后一天完成所有任务。需要注意的是，理想燃尽线只是理想情况，实际上没有任何一个团队在任何一个Sprint中能够按照理想燃尽线执行。

图9-5Sprint燃尽图示例

在每日站会上，团队对已经启动但是未完成的任务要重新估算时间。尤其要注意的是，当团队对每个进行中的任务估算还需要多长时间时，不是用大家直觉的算法，即任务的初始估算时间减去实际花费时间。

举例来说，一个任务原来估算是8小时，按理说，一天可以完成，可是，实际情况比想象的要困难很多，团队估算还需要8小时。这就是为什么燃尽图不统计团队实际花了多长时间的原因，因为已经花的时间是沉没成本，与还剩多少工作无关。

Scrum团队每天估算的剩余工时情况如表9-3所示。

表9-3Scrum团队每天估算的剩余工时示例（单位：天）

团队每天将估算的剩余任务的小时数相加，绘制成实际燃尽线。燃尽图的最大作用是预警交付风险。当实际燃尽线低于理想燃尽线的时候，团队可能会提前完成Sprint计划的工作，此时，团队仍需继续保持现有的速度；当实际燃尽线高于理想燃尽线的时候，团队可能会完不成该Sprint的工作，此时，ScrumMaster需要提醒团队加速前进。

问：什么样的燃尽线比较好呢？

答：没有好与不好之分。Sprint燃尽的过程千差万别，但是，只要最终在Sprint截止日达到Sprint目标，Sprint就是成功的。燃尽图每天给团队一个进度反馈，用数据告诉团队是否会有达不成Sprint目标的风险。

在应用燃尽图的过程中，很多团队发现按照任务剩余工时来指导工作有个缺点，即工时的燃尽不代表价值的交付，即使某一天工时燃了很多，但是团队一个用户故事都没完成，也不能代表价值交付。于是一些团队开始用另一种燃尽图方法，如图9-6所示。

图9-6以用户故事为线索的燃尽图示例

用户故事燃尽图的实际燃尽线就像楼梯一样，不是一条斜线。如果团队一天甚至几天都没有完成一个用户故事，那么实际上这段时间内的燃尽线就是平的。

3.版本燃尽图

Scrum团队可以用版本燃尽图来预测版本的发布时间，如图9-7所示。

• 横轴：Sprint周期。
• 纵轴：该版本未完成的用户故事点数。
  

在图9-7中，该版本一共有28个点。团队在第一个Sprint完成了15个点，该版本还剩13个点。团队在第二个Sprint完成了1个点，该版本还剩12个点。团队在第三个Sprint完成了8个点，该版本还剩4个点。团队在第四个和第五个Sprint没有完成任何用户故事，于是该版本还剩4个点。最近连续3个Sprint速率：（8+0+0）/3≈3个点。按照这个速率，团队至少还需要2个Sprint（剩余4个点/速率3个点＝1.3）才能完成这个版本的交付。

图9-7版本燃尽图示例

资料来源：电子工具JIRASoftware绘制的版本燃尽图

4.看板累积流图

累积流图是看板方法里的核心度量之一，它可以很好地反映工作项在每个流程环节中的流动问题。但是由于这个度量图表比较抽象，导致很多团队想用但不会用。因此，要想知道怎么用，首先要理解这个图是怎么画出来的。

团队在每天站会的时候，会记录看板上处于各个流程阶段的在制品数量，每个流程阶段用不同的颜色绘制，这样每天连续记录，就绘出了累积流图。举例来说，某团队今天站会上的看板如图9-8所示。

累积流图的绘制方法如下。首先，绘制横轴和纵轴。

• 横轴：时间（天）。
• 纵轴：工作项数量（个）。
  

然后，通过数看板上的工作项数量绘制累积流图，如图9-9所示。

（1）今天在“完成”列上有2个工作项。于是，在横轴为“今天”、纵轴为“2”的位置打个绿色的点，表示累计共完成了2个工作项。为简单起见，我们把绿线称为“完成线”。

（2）“测试”列有2个工作项，“完成”列与“测试”列共计4个工作项。于是，在横轴为“今天”、纵轴为“4”的位置打个蓝色的点，表示进入测试环节累计4个工作项，包括正在测试和测试完成的所有工作项。我们把蓝线称为“进入测试线”。

图9-8看板示例

（3）“开发”列（包括“开发进行中”列和“开发完成”列）共3个在制品，“开发”列、“测试”列与“完成”列合计7个工作项。于是，在横轴为“今天”、纵轴为“7”的位置打个红色的点，表示累计进入开发环节共7个工作项，包括开发进行中、开发完成、测试进行中、测试完成的所有工作项。我们把红线称为“进入开发线”。

（4）“Backlog”列有7个在制品，“Backlog”列、“开发”列、“测试”列与“完成”列合计14个工作项。于是，在横轴为“今天”、纵轴为“14”的位置打个黄色的点，表示累计进入“Backlog”列共14个工作项，包括当前在Backlog中、开发进行中、开发完成、测试进行中、测试完成的所有工作项。我们把黄线称为“进入Backlog线”。

这样在每日站会后打点更新，连续多天就会形成类似图9-9的累积流图。

图9-9累积流图示例

如图9-9所示，借助累积流图，我们能够分析出以下有价值的信息。

• 在制品（WIP）。看纵轴：从“进入开发线”到“完成线”之间的高度，代表了整个看板的在制品数量，因此这个高度的变化反映了在制品数量的变化。如果某个流程环节与下一个流程环节之间的高度差比较高（在累积流图上体现为两条线之间的高度），可能暗示了研发流程在该处有瓶颈或超负载工作等问题，亟须解决。
• 平均周期时间（AverageLeadTime）。看横轴：从“进入开发线”到“完成线”之间的长度，代表了从开发启动到完成的周期。这个长度的变化反映了团队交付能力的变化。如果某个流程环节的水平长度较长（在累积流图上体现为两条线之间的水平长度），说明该流程环节的周期长，这往往是由于该环节的在制品堆积造成的。
• 吞吐率（Throughput）。在累积流图中，“完成线”的斜率就是吞吐率。通过观察“完成线”的斜率的变化，就可以直观地看出团队交付效率的变化。
• 需求范围的变化。“进入Backlog线”的高度反映了Backlog里所有工作项的数量。这条线变高说明有新的需求进入了Backlog。如果这条线在一段时间内是平的，表示这段时间Backlog里没有进入新的需求；如果这条线变低，说明有些需求从Backlog里被删除了。
• 预测交付日期。按照当前的斜率画出“完成线”的延长线，它与“进入Backlog”线的交点，就是按照当前的吞吐率交付Backlog里所有工作项的预计日期。这个预测随着Backlog范围的变化以及吞吐率的变化而改变（如图9-10所示）。
  

图9-10累积流图分析示意图

5.看板周期时间分布图

工作项的周期时间（LeadTime）指的是工作项从进入看板的就绪队列开始流动，直到流动到看板最后一列所耗费的时间。周期时间分布图是将每一个工作项的周期时间作为统计单位的直方图。举例来说，某团队在回顾会议上统计了本月交付的每个工作项的周期时间（如表9-4所示）。

表9-4工作项周期时间统计表

上表中最后一行共有1个工作项，其周期时间为14天。按照这个表绘制的周期时间分布图如图9-11所示。

通过对图9-11的分析，我们可得出如下信息。

（1）通过量化的交付能力做出靠谱的预测和承诺。通过表9-4，我们可以统计出所有工作项的平均交付周期时间为8天。按照表中的统计，团队有85%的工作项在11天以内完成。于是，当有一个新的工作项被拉入看板的就绪队列中时，团队就可以做出如下承诺：基于过去的交付能力，我们有85%的信心在11天以内完成。当然，还要具体看工作项的规模和复杂程度，但是这个概率水平给了团队基于历史数据对外做出承诺的信心。

（2）每个团队的周期时间分布图都不同，而且会随着时间和团队能力的发展而变化。因此，分布图为团队指明了改进方向。对此，我们可以从这几个方面分析周期时间分布图。

图9-11周期时间分布图示例

• 看图的尾巴。如果分布图的尾巴很长，说明团队的交付时间离散，交付能力不稳定。这样的团队，其工作完成交付的可预测性偏弱。团队需要回顾处于分布图尾部的那些工作项的价值流动过程，分析是什么原因导致周期时间偏长。
• 波峰的位置。如果分布图中波峰的位置靠右，说明团队的交付周期时间偏长，整体的交付能力薄弱。团队需要反思：为什么每个工作项的交付周期会这么长？工作项是否已经拆分到最小单位？如果已经拆分到最小单位，如何才能缩短交付周期？
• 波峰的高度。分布图中波峰的位置越高，说明分布越集中，从而团队交付周期的可预测性越强。如果分布图扁平，那么一定有大量的离散点，说明团队交付周期的时间跨度很大。团队应该回顾并分析：如何提高可预测性？比如，团队可以尝试将需求粒度拆分得更加均匀，让工作项流动得更加顺畅。
  

关于影响价值交付效率的因素，我们可以就如下方面进行分析。

1.速率

速率指的是团队对一个Sprint里完成的工作的度量，单位可以是用户故事的点数、理想人天，或者是用户故事的数量。一个Sprint结束的时候，团队应该统计实际完成的速率与计划的速率之间的比值，并且对没完成的用户故事做回顾，看看需要采取什么改进措施。

一般来说，速率的统计用柱状图表示，如图9-4所示。

图9-4速率统计示意图

资料来源：电子工具JIRASoftware绘制的速率统计图

图9-4中“已承诺”所代表的柱状图是每个Sprint承诺的速率，“已完成”所代表的柱状图是每个Sprint实际完成的速率。每个Sprint实际完成的速率可作为后续Sprint计划的参考。

速率的统计不一定需要电子工具，手工绘制、Excel都可以。

某Scrum团队连续四个Sprint的实际速率与计划速率的对比如表9-2所示。

表9-2速率示例

该团队的计划有很大的问题：连续三个Sprint都没有完成计划的Backlog，而且每个Sprint的实际速率与计划速率相差很大；经计算得出，连续三个Sprint的实际平均速率是32个故事点，在这样的速率下，却计划在第四个Sprint完成92个故事点。当时，我问这个团队做出这样的计划是怎么考虑的？团队的回答是：“计划只是个计划，我们就是要制订一个非常有挑战的计划，完不成没关系。”对此，我认为这样的团队长此以往下去，会逐渐失去与产品负责人彼此之间的信任。

2.Sprint燃尽图

燃尽图的全称是“总剩余工时的燃尽图”，指的是当前Sprint计划的用户故事被拆分的所有任务，其剩余估算时间总和随着日期的变化而逐日递减的统计图，如图9-5所示。

例如，在Sprint计划会议结束后，团队统计出所有计划的用户故事被拆分成的任务，其估算时间之和为50个小时，于是初始点被打在横坐标0、纵坐标50的位置上。由初始点和Sprint的最后一天所连成的线是理想燃尽线，即如果团队每天匀速完成等量时间的任务，那么就应该在Sprint的最后一天完成所有任务。需要注意的是，理想燃尽线只是理想情况，实际上没有任何一个团队在任何一个Sprint中能够按照理想燃尽线执行。

图9-5Sprint燃尽图示例

在每日站会上，团队对已经启动但是未完成的任务要重新估算时间。尤其要注意的是，当团队对每个进行中的任务估算还需要多长时间时，不是用大家直觉的算法，即任务的初始估算时间减去实际花费时间。

举例来说，一个任务原来估算是8小时，按理说，一天可以完成，可是，实际情况比想象的要困难很多，团队估算还需要8小时。这就是为什么燃尽图不统计团队实际花了多长时间的原因，因为已经花的时间是沉没成本，与还剩多少工作无关。

Scrum团队每天估算的剩余工时情况如表9-3所示。

表9-3Scrum团队每天估算的剩余工时示例（单位：天）

团队每天将估算的剩余任务的小时数相加，绘制成实际燃尽线。燃尽图的最大作用是预警交付风险。当实际燃尽线低于理想燃尽线的时候，团队可能会提前完成Sprint计划的工作，此时，团队仍需继续保持现有的速度；当实际燃尽线高于理想燃尽线的时候，团队可能会完不成该Sprint的工作，此时，ScrumMaster需要提醒团队加速前进。

问：什么样的燃尽线比较好呢？

答：没有好与不好之分。Sprint燃尽的过程千差万别，但是，只要最终在Sprint截止日达到Sprint目标，Sprint就是成功的。燃尽图每天给团队一个进度反馈，用数据告诉团队是否会有达不成Sprint目标的风险。

在应用燃尽图的过程中，很多团队发现按照任务剩余工时来指导工作有个缺点，即工时的燃尽不代表价值的交付，即使某一天工时燃了很多，但是团队一个用户故事都没完成，也不能代表价值交付。于是一些团队开始用另一种燃尽图方法，如图9-6所示。

图9-6以用户故事为线索的燃尽图示例

用户故事燃尽图的实际燃尽线就像楼梯一样，不是一条斜线。如果团队一天甚至几天都没有完成一个用户故事，那么实际上这段时间内的燃尽线就是平的。

3.版本燃尽图

Scrum团队可以用版本燃尽图来预测版本的发布时间，如图9-7所示。

• 横轴：Sprint周期。
• 纵轴：该版本未完成的用户故事点数。
  

在图9-7中，该版本一共有28个点。团队在第一个Sprint完成了15个点，该版本还剩13个点。团队在第二个Sprint完成了1个点，该版本还剩12个点。团队在第三个Sprint完成了8个点，该版本还剩4个点。团队在第四个和第五个Sprint没有完成任何用户故事，于是该版本还剩4个点。最近连续3个Sprint速率：（8+0+0）/3≈3个点。按照这个速率，团队至少还需要2个Sprint（剩余4个点/速率3个点＝1.3）才能完成这个版本的交付。

图9-7版本燃尽图示例

资料来源：电子工具JIRASoftware绘制的版本燃尽图

4.看板累积流图

累积流图是看板方法里的核心度量之一，它可以很好地反映工作项在每个流程环节中的流动问题。但是由于这个度量图表比较抽象，导致很多团队想用但不会用。因此，要想知道怎么用，首先要理解这个图是怎么画出来的。

团队在每天站会的时候，会记录看板上处于各个流程阶段的在制品数量，每个流程阶段用不同的颜色绘制，这样每天连续记录，就绘出了累积流图。举例来说，某团队今天站会上的看板如图9-8所示。

累积流图的绘制方法如下。首先，绘制横轴和纵轴。

• 横轴：时间（天）。
• 纵轴：工作项数量（个）。
  

然后，通过数看板上的工作项数量绘制累积流图，如图9-9所示。

（1）今天在“完成”列上有2个工作项。于是，在横轴为“今天”、纵轴为“2”的位置打个绿色的点，表示累计共完成了2个工作项。为简单起见，我们把绿线称为“完成线”。

（2）“测试”列有2个工作项，“完成”列与“测试”列共计4个工作项。于是，在横轴为“今天”、纵轴为“4”的位置打个蓝色的点，表示进入测试环节累计4个工作项，包括正在测试和测试完成的所有工作项。我们把蓝线称为“进入测试线”。

图9-8看板示例

（3）“开发”列（包括“开发进行中”列和“开发完成”列）共3个在制品，“开发”列、“测试”列与“完成”列合计7个工作项。于是，在横轴为“今天”、纵轴为“7”的位置打个红色的点，表示累计进入开发环节共7个工作项，包括开发进行中、开发完成、测试进行中、测试完成的所有工作项。我们把红线称为“进入开发线”。

（4）“Backlog”列有7个在制品，“Backlog”列、“开发”列、“测试”列与“完成”列合计14个工作项。于是，在横轴为“今天”、纵轴为“14”的位置打个黄色的点，表示累计进入“Backlog”列共14个工作项，包括当前在Backlog中、开发进行中、开发完成、测试进行中、测试完成的所有工作项。我们把黄线称为“进入Backlog线”。

这样在每日站会后打点更新，连续多天就会形成类似图9-9的累积流图。

图9-9累积流图示例

如图9-9所示，借助累积流图，我们能够分析出以下有价值的信息。

• 在制品（WIP）。看纵轴：从“进入开发线”到“完成线”之间的高度，代表了整个看板的在制品数量，因此这个高度的变化反映了在制品数量的变化。如果某个流程环节与下一个流程环节之间的高度差比较高（在累积流图上体现为两条线之间的高度），可能暗示了研发流程在该处有瓶颈或超负载工作等问题，亟须解决。
• 平均周期时间（AverageLeadTime）。看横轴：从“进入开发线”到“完成线”之间的长度，代表了从开发启动到完成的周期。这个长度的变化反映了团队交付能力的变化。如果某个流程环节的水平长度较长（在累积流图上体现为两条线之间的水平长度），说明该流程环节的周期长，这往往是由于该环节的在制品堆积造成的。
• 吞吐率（Throughput）。在累积流图中，“完成线”的斜率就是吞吐率。通过观察“完成线”的斜率的变化，就可以直观地看出团队交付效率的变化。
• 需求范围的变化。“进入Backlog线”的高度反映了Backlog里所有工作项的数量。这条线变高说明有新的需求进入了Backlog。如果这条线在一段时间内是平的，表示这段时间Backlog里没有进入新的需求；如果这条线变低，说明有些需求从Backlog里被删除了。
• 预测交付日期。按照当前的斜率画出“完成线”的延长线，它与“进入Backlog”线的交点，就是按照当前的吞吐率交付Backlog里所有工作项的预计日期。这个预测随着Backlog范围的变化以及吞吐率的变化而改变（如图9-10所示）。
  

图9-10累积流图分析示意图

5.看板周期时间分布图

工作项的周期时间（LeadTime）指的是工作项从进入看板的就绪队列开始流动，直到流动到看板最后一列所耗费的时间。周期时间分布图是将每一个工作项的周期时间作为统计单位的直方图。举例来说，某团队在回顾会议上统计了本月交付的每个工作项的周期时间（如表9-4所示）。

表9-4工作项周期时间统计表

上表中最后一行共有1个工作项，其周期时间为14天。按照这个表绘制的周期时间分布图如图9-11所示。

通过对图9-11的分析，我们可得出如下信息。

（1）通过量化的交付能力做出靠谱的预测和承诺。通过表9-4，我们可以统计出所有工作项的平均交付周期时间为8天。按照表中的统计，团队有85%的工作项在11天以内完成。于是，当有一个新的工作项被拉入看板的就绪队列中时，团队就可以做出如下承诺：基于过去的交付能力，我们有85%的信心在11天以内完成。当然，还要具体看工作项的规模和复杂程度，但是这个概率水平给了团队基于历史数据对外做出承诺的信心。

（2）每个团队的周期时间分布图都不同，而且会随着时间和团队能力的发展而变化。因此，分布图为团队指明了改进方向。对此，我们可以从这几个方面分析周期时间分布图。

图9-11周期时间分布图示例

• 看图的尾巴。如果分布图的尾巴很长，说明团队的交付时间离散，交付能力不稳定。这样的团队，其工作完成交付的可预测性偏弱。团队需要回顾处于分布图尾部的那些工作项的价值流动过程，分析是什么原因导致周期时间偏长。
• 波峰的位置。如果分布图中波峰的位置靠右，说明团队的交付周期时间偏长，整体的交付能力薄弱。团队需要反思：为什么每个工作项的交付周期会这么长？工作项是否已经拆分到最小单位？如果已经拆分到最小单位，如何才能缩短交付周期？
• 波峰的高度。分布图中波峰的位置越高，说明分布越集中，从而团队交付周期的可预测性越强。如果分布图扁平，那么一定有大量的离散点，说明团队交付周期的时间跨度很大。团队应该回顾并分析：如何提高可预测性？比如，团队可以尝试将需求粒度拆分得更加均匀，让工作项流动得更加顺畅。