第十三讲 Product Backlog

在讲Product Backlog产品待办列表前，我们先回顾一下前十二讲中相关的内容。

第二讲《Scrum概述》，讲到Scrum的理论基础是经验型流程，经验型流程有三大支柱：透明、检视、调整。Scrum为检视和调整规定了4个正式事件：Sprint Planning、Daily Scrum、Sprint Review和Sprint Retrospective。Sprint Review 检视和调整什么？检视Increment，调整Product Backlog。Sprint Retrospective 检视和调整什么？检视和调整Process。

Scrum是怎样实现透明的呢？Scrum用3个工件体现工作和价值，提高透明度，为检视和调整提供机会。这3个工件分别是Product Backlog，Sprint backlog和Increment。第八讲《冲刺和增量》里，我们已经讨论了增量。第十三讲，我们详细讨论Product Backlog.

讨论主题 

1.什么是Product Backlog?

2.好的Product Backlog有什么特点?

3.怎样使Product Backlog具备这些特点?

4.怎样使用Product Backlog?

一、什么是Product Backlog?

Product Backlog，中文名称叫产品待办列表。Product Backlog是一个按优先顺序排列的列表，它展现出想要得到的产品功能。产品将要构建什么特性？以什么样的顺序构建？对于这些干系人共同关心的问题，Product Backlog提供了一个集中的、共享的信息源。这就是我们刚才提到的透明。

一个Product Backlog由多个Product Backlog Item组成，这个Product Backlog Item，中名称叫产品待办项，英文简称PBI。Product Backlog里面的这些PBI，不仅可以是新特性，可以是对已有特性的修改，还可以是bug，或者是重构任务。对用户或客户来说，大多数PBI是有实际价值的特性。不过，只要Product Owner认为有价值，任何工作都可以作为一个PBI放在Product Backlog 里。

Product Owner对Product Backlog负责，包括增加新的PBI，修改或删除PBI，以及把PBI按照优先级排序。

二、好的Product Backlog有什么特点?

一个好的Product Backlog应该具有4大特征：详略得当(Detailed appropriately)、涌现的(Emergent)、做过估算的(Estimated)、和排列好顺序的(Prioritized)。这四个英文单词的首字母正好构成单词DEEP，我们称之为DEEP标准。

详略得当(Detailed appropriately)

在同一时刻，一个Product Backlog里的PBI，有的应该详细，有的应该粗略。马上要做的PBI放在Product Backlog顶部。这些PBI需要详细，具体指：

·描述非常详细，能清楚表达业务价值，开发人员能够理解；

·有清晰的接收标准，可测试；

·工作量足够小，小到每个PBI可以在一个Sprint中完成。

短时间内还不打算做的PBI放在Product Backlog底部。这些PBI不需要那么详细，粗略即可，具体指：

·描述粗略，不包含细节;

·工作量大，需要多个Sprint才能完成。

涌现的(Emergent)

Product Backlog是一个活的工件，是动态的，需要持续更新。只要产品存在，需要开发或维护，Product Backlog就存在。

早期的Product Backlog列出我们最初知道的、理解的最透彻的需求。随着产品本身及其外部应用环境的演进，Product Backlog需要不断演进。就产品本身而言，产品被客户使用，市场提供反馈，那么Product Backlog应该体现市场反馈中的那些有价值的信息。就外部应用环境而言，业务需求会变化，例如，客户可能突然改变了他们的想法；市场环境会变化，例如，竞争对手可能采取了冒失的、不可预测的行动。这些变化都是具有经济价值的信息。响应变化，才能使产品具有市场竞争力。随着这些信息的不断涌入，Product Backlog需要持续更新，变得越来越长，越来越详尽。这就是涌现。

做过估算的(Estimated)

放在Product backlog顶部的PBI，马上就做，需要有较准确的工作量估算。放在Product Backlog底部的PBI，短时间内还不打算做，有大致的估算即可，不估算也可以。

排列好顺序的(Prioritized)

例如一个产品有中长期发布计划，近期发布版本1，中期发布版本2，远期要发布版本3，那么整个Product Backlog就可以按照版本1、2、3排出优先级的高、中、低三大块。在近期要发布的版本1中的PBI，排好优先顺序很有用。在版本2和版本3中的PBI，就不值得再花时间排优先级。

三、怎样使Product Backlog具备这些特点?

为了使Product Backlog具体上述4个特点，Scrum团队需要适时的对Product Backlog进行梳理。

什么是梳理

梳理指三大重要的活动：创建并细化PBI(增加PBI的细节)；对PBI进行估算；为PBI排列优先顺序。

例如，在得到重要的信息后，需要创建新的PBI，并把它插入到Product Backlog里的正确的位置。如果有一个PBI很大，比如一个史诗(epic)，我们决定近期就做，就需要把它分解为一组小的用户故事，为每个用户故事添加细节，做准确的估算，并调整这些细分出来的PBI在Product Backlog里的位置。如果认定某个特定的PBI已经不再需要，删掉即可。

谁来梳理？

梳理活动由Product Owner牵头，开发团队和Scrum Master以及干系人协助。

Product Owner一方面负责创建和细化PBI，分析PB的价值，另一方面，要帮助开发团队理解PBI，以便开发团队能够对PBI的工作量做出准确的估算。开发团队在每个Sprint中，用不到10%的时间来协助Product Owner对PBI进行工作量估算，还要帮助Product Owner根据技术依赖关系和资源约束，来排列PBI的优先顺序。Product Owner根据PBI价值、工作量等多方面因素，对PBI排序，力求最大化产品价值，使投入产出比达到最优。Scrum Master需要支持Product Owner梳理Product Backlog，引导开发团队进行估算，协调Product Owner和开发团队之间的配合。

怎样梳理？

排序受到很多因素的影响，其中最重要的是商业价值和成本。图中红色框标出的高价值、低成本的PBI应该给予最高优先级，排在Product Backlog的最顶端。

在考虑商业价值的时候，必然涉及到客户满意度。这里仅就产品特性对客户满意度的影响展开进一步讨论。

KANO模型

Product Owner怎样分析产品特性对客户满意度的影响呢？我们介绍KANO模型。

KANO模型将影响满意度的因素划分为如下几个类型，包括：

基本型需求(见图中绿色曲线)

基本型需求是顾客认为产品的必备属性。当其具备程度低时，顾客很不满意。即使其具备程度高，顾客充其量达到满意。例如，一个智能手机通话质量差，用户非常不满，但通话质量好，客户只是觉得这是应该的。

期望型需求(见图中青色直线)

当此类需求得不到满足，客户的不满显著增加；此类需求得到满足的话，客户满意度也会显著增加。

魅力型需求(见图中红色曲线)

魅力型需求指不会被顾客过分期望的需求。期望得不到满足，顾客也不会因此表现出明显的不满意。随着满足顾客期望程度的增加，顾客满意度会急剧上升。

Product Owner为PBI排序时，首先要全力以赴地满足顾客的基本型需求，然后尽力去满足顾客的期望型需求，最后争取实现顾客的魅力型需求，为企业建立最忠实地客户群。

计划扑克

开发团队怎样估算PBI的工作量呢？我们介绍计划扑克。

玩计划扑克的规则如下：

1、Product Owner选择一个需要估算的PBI，把它读给开发团队;

2、开发团队成员讨论，并向Product Owner提出要求澄清的问题，Product Owner负责回答;

3、每个开发者手里有一副牌，私下选择一张，用牌上的数字代表他的估算，扣在桌面上;

4、每个人都做出自己的选择后，Scrum Master宣布同时亮牌;

5、如果大家选的牌上的数字一样，就说明达成了共识，这个共同的数字就是PBI的估算值;

6、如果大家的估算不同，团队成员需要讨论，暴露开发者之间不同的假设和对PBI误解;

7、讨论之后，返回到第3步，重复上述步骤直到达成共识;

这里Scrum Master要掌控几个要点:

1、估算活动由开发团队集体进行。

2、计划扑克上的“1”代表多大的工作量，由开发团队自己定义，可以定义为一个人*天的工作量。不同开发团队，开发经验不同，效率不同，习惯不同，“1”代表什么也不同。在不同团队之间，估算点数不可比。

3、使用相对估算，而不是绝对估算。确定了单位“1”以后，其他PBI的工作量是单位“1”的几倍，就选几。

4、要求同时亮牌，保证每个参加估算的人都能独立思考。

5、当大家的估算不同，不建议取平均值。建议把各自的理由说出来，充分讨论，以澄清一些假设和误解。

6、不建议把估算准确与否和奖金挂钩，奖金刺激会导致估算值远大于实际值。

四、怎样使用Product Backlog？

监控目标实现的进度

与做完了什么相比，敏捷更关注为了实现目标，还有什么要做？Product Owner对照目标(例如版本计划，产品愿景)，总结Product Backlog里的内容，就可以知道距离目标实现还有多远。Product Owner在每个Sprint Review的时候，把当前的Product Backlog和上一个Sprint Review时的Product Backlog对比，就可以监控目标实现的进度。

下图展示了一个固定范围版本的燃尽图。可以看到，固定版本范围预估的总故事点数是150，每个Sprint完成十几个故事点，那么剩余的故事点就越来越少，距离版本发布的目标就越来越近。通过观察燃尽图，可以监控目标实现的进度。

管理版本工作流

版本可以看成是穿过Product Backlog的线。版本线上方的所有PBI都预计在这个版本中完成，线下方的PBI则不在这个版本中。下图每个版本用两条线来划分Product Backlog。这两条线把Product Backlog分成三段：“必须有的”、“最好有的”和“不会有的”。“必须有的”特性代表接下来的版本必须要有的PBI，否则就不会有一个可行的版本来吸引客户。“最好有的”特性代表下一版本打算，并希望包含在版本中的条目，不过，如果时间或其他资源不足，“最好有的”特性可以去掉，得到的产品仍然可以交付。“不会有的”特性是我们宣布当前版本中不会包含的特性。以这种方式维护Product Backlog，可以帮助我们更好的持续进行版本规划。

管理冲刺工作流

Ken Rubin把Product Backlog比做管道中的需求，它们流入Sprint，由团队设计、构建并测试。需求从左端流入管道的时候，是粗略的，在流经管道的过程中，被逐步细化，在快要流出管道时，是详细的、处于“Ready”状态的，是团队能够理解并很容易在一个Sprint中交付的。

如果流入流出的PBI不平衡，就会有问题。如果流的太慢，到Sprint Planning的时候，PBI不够一个Sprint的工作量，或者PBI非常粗略，开发团队看不懂，会导致开发团队无法进行下一个Sprint。如果流的太快，把过多PBI放入管道中细化，可能需要返工，甚至舍弃一些需求，造成浪费。因此我们推荐一个经验值，即“准备好两三个Sprint的PBI”。如果团队每个冲刺一般能做大约5个PBI，那么团队在梳理列表时，任何时候总有大约10到15个PBI是准备就绪的。

小结 

第十三章讨论了4个主题

1.什么是Product backlog?

Product Backlog是一个按优先顺序排列的列表，它展现出想要得到的产品功能。

2.好的Product Backlog有什么特点?

一个好的Product Backlog应该符合DEEP标准：详略得当(Detailed appropriately)、涌现的(Emergent)、做过估算的(Estimated)和排列好顺序的(Prioritized)。

3.怎样使Product Backlog具备这些特点?

需要对Product Backlog进行梳理。要创建并细化PBI；对PBI进行估算；为PBI排列优先顺序。关于PBI排序，我们介绍了KANO模型。关于PBI估算，我们介绍了怎样玩计划扑克。

4.怎样使用Product Backlog?

我们可以使用Product Backlog监控目标实现的进度，管理版本工作流，管理冲刺工作流。