敏捷开发：Scrum 中的 Product Backlog 介绍

Product Backlog 产品待办列表

在计划开发产品功能时，都希望产品功能上线后，用户能够喜欢并经常使用。

因此在开发产品新功能时，就要衡量哪些产品需求是对用户最有价值，这是最应该思考的问题。

然后把这些有价值的需求集合放在一起。当然，也有与需求实现相关的其它工作项。

在 Scrum 框架中，把产品待开发的功能集合放在一起就叫产品待办列表（Product Backlog）。它是 Scrum 团队实现产品目标所需完成的所有工作项的集合，是 Scrum 团队进行工作规划和执行的来源。它由产品负责人维护。

英文 backlog 意思是：大量堆积、积压的事物或工作，也指"尚未完成的工作"，或"需要尽快处理的事情"。

在产品待办列表中的工作项叫产品待办事项（Product Backlog Item）。

如果待开发功能很多，那哪些功能优先开发？这就需要对产品待办列表里的功能集做一个优先级排序，优先级高的率先开发。

当然，随着开发的持续进行，产品待办列表中可能有不止功能性需求，还有非功能性特性。

比如：bug缺陷修复、基础技术任务、比较大的用户故事（Epic）、代码改进、架构优化、功能优化等等。

产品待办列表特点

1、优先级排序：产品待办列表是一个按照优先级从高到低进行排序的产品功能列表。它包含了产品有价值的需求、Bug修复、特性等列表项。
2、动态变化：产品待办列表是一个动态变化的列表，随着项目功能不断开发，市场不断变化，用户持续的反馈，获取的信息和知识也越来越多，产品负责人可能会不断的更新项目列表，添加新的需求或特性、调整优先级、移除不再重要的功能等等。
产品待办列表的持续更新和改进有助于团队适应变化，并持续提供价值。
3、需求细节详情：把将要在下一个迭代（Sprint Backlog）中完成的待办项，描述时包含足够的细节。比如用户故事，大小合适并且符合 INVEST 原则，用户故事三要素俱全，分解成故事点（用于估算工作量）。
4、透明性：产品待办列表是 Scrum 团队实现产品目标所需完成的所有工作项的集合，确保团队成员都清楚产品要完成的工作项、方向和目标。团队成员需要完成哪些工作都是来自这里。
5、工作集：上面已经说明，产品待办列表是 Scrum 团队实现产品目标所需完成的所有工作项的集合。

产品待办列表管理

产品待办列表（Product Backlog）是由产品负责人（Product Owner）负责管理的。

随着产品功能不断开发，用户持续反馈，市场不断变化，获取的知识增多，涌现新的想法，待办列表里的工作项会不断进行改变和调整。待开发项（item）是随用户、市场不断变化、持续演进的。

（from：https://www.visual-paradigm.com/cn/scrum/what-is-product-backlog-in-scrum/1000）

那怎么管理变化，把这种变化反映到开发项中呢？那哪些又是不变的呢?

产品愿景。这是不变的，它将作为指导产品待办列表中工作项的创建、移除、修改。

变化的工作项，定期进行梳理，可以用 梳理会议 来进行管理。产品负责人可以通过定期举办梳理会议来梳理产品待办列表。

梳理会议 的一些关键活动：

1、梳理产品愿景。

2、创建、移除、调整产品待办列表项。

3、拆分大的待办项，比如 Epic（史诗）。产出合适大小的用户故事。

4、澄清待办项。

5、排列、修改优先级排序。

6、利益相关者的沟通。

7、产品阶段性目标。

8、待办项的估算。

会议参与方：

产品负责人、Scrum Master、产品开发人员、业务部门人员（市场、销售、业务、客服等）、产品经理、产品设计人员

为什么会有这么多人参与呢？

因为产品待办项的内容来源，是由上述人员或部门提出的。他们会根据市场需求、用户反馈、功能改进、技术重构等因素提出新的需求或改进点。

注意点，整理待办项时需注意点：

这时候需求不需要事无巨细，做到最基本的描述，力求简洁。
可以用户故事来描述需求，用卡片方式，前一节有讲解。
低优先级的需求条目可能数量大，而且是粗粒度。
非功能性需求，尽早描述详情，因为可能对整个产品体验产生很大影响。

用户故事拆分方法

把比较大的故事比如 Epic，拆分成小的故事。用户故事的一些拆分方法：

按照工作流程步骤拆分。要完成一个故事，需要哪些步骤，按照一个步骤一个步骤来进行拆分。
按照不同业务规则拆分。
按照操作来拆分。比如增加、删除、管理等操作来进行拆分。
按照依赖先后顺序拆分。比如一个故事开发依赖后一个故事，那么这个后一个故事先开发。
按简单/复杂进行拆分。比如先做简单的故事，后做复杂的故事。

产品待办列表优先级评估介绍

产品待办列表里有很多待办项，哪些待办项首先做，哪些后面做？可以对待办项进行优先级评估然后排序。

对这些待办项进行排序后，接下来，在冲刺（Sprint）计划会议就可以安排哪些待办项先进行开发。

优先级评估的原则依据有哪些？

价值（用户价值和商业价值）
成本
实现难度
风险大小
可发布性

用户价值、商业价值：

做产品，是解决用户问题，给用户带来价值。需经常问自己："做这个需求能给用户解决什么问题带来什么价值；不做呢？产品会有什么损失，用户会有什么损失？"

当然，更希望产品给公司带来商业价值。

成本：

估算实现的成本。比如人工成本，工作量大小，协同成本。

实现难度：

实现这个需求或特性，技术难度高不高。比如：实现此需求代码改动大；需进行技术预研；依赖其它需求的实现等等。

需求细化成更小故事后，可以用工作量来衡量。

风险大小：

做需求或特性，风险点有哪些，然后进行讨论评估。比如说做创新产品，不确定性肯定高。

可发布性：

对于产品功能，开发后的产品增量需要尽快发布，更早得到用户反馈。

优先级评估方法或模型介绍

产品待办列表的需求评估优先级，可以采用多种方法，下面列举一些常见评估方法。

KANO 模型

此模型通过客户对功能满意度来确定优先级，将功能分为必备型需求、期望型需求、魅力型需求、无差异需求、反向型需求。

from： https://baike.baidu.com/item/KANO 模型/19907824

KANO模型需求分类：

必备型需求（属性）（一定要有）：有的也译作基本型需求（属性）。用户认为理所应当、必须要有的需求，这些需求必须被满足。当这些需求不被满足时，也就是不提供这些需求，用户满意度会大幅降低；当这些需求被满足时，用户满意度不会得到提升。例如：手机打电话、发短信。
期望型需求（属性）：满足此需求时，用户满意度会提升；不满足此需求时，用户满意度会降低。
魅力型需求（属性）：用户对这种需求没有太大期望，需要产品经理对用户有深刻的洞察才能挖掘到此隐性需求，属于给用户惊喜的需求。不满足此需求，用户满意度不会降低；满足此需求，用户满意度会急剧提升。有时是产品很有竞争力的体现。
无差异需求（属性）：无论是否满足此需求，对用户满意度都不会产生影响。
反向型需求（属性）：有无此类需求，用户根本不在意。若满足此需求，用户满意度反而会下降。

它们的优先级排序为：

必备型需求 > 期望型需求 > 魅力型需求 > 无差异需求

四象限法

四象限法是按照重要和紧急 2 个不同的纬度进行划分，将需求放在二维或三维角度进行优先级的决策。

按重要和紧急 2个维度，将需求任务划分为【重要且紧急】、【重要不紧急】、【不重要但紧急】以及【不紧急不重要】四类。

需求任务分成四个象限：重要紧急 > 重要不紧急 > 不重要但紧急 > 不重要不紧急

重要紧急：重要紧急的需求任务，对产品影响很大，第一时间处理。
重要不紧急：这种类型的任务可以把它纳入计划，按计划完成。
不重要但紧急：如果任务小花费时间少，可以马上去执行完成。如果比较耗时，可以另外安排时间或交付给他人去做。
不重要不紧急：可以尽量不做。

注意点：

紧急不等于重要：紧急的任务，不等于重要的任务。比如当我们时刻关注用户反馈，每天都有很多问题，这些有的是紧急但对产品影响不大的问题，在某个时间点完成就可以，对最终结果影响不大。

需求是变的：一般我们都是关注重要且紧急的任务，但是随着需求的调整，其它类型的任务也会上升到重要且紧急的任务象限内。

RICE 框架

RICE 这个框架由 Intercom提出，旨在平衡成本和收益的系统，对需求进行评估。

RICE 框架是一种量化需求优先级的模型，通过 4 个维度来给需求打分，然后算出最终得分。通过比较每个需求的得分来排定需求优先级顺序。

(from：intercom：rice-simple-prioritization-for-product-managers)

RICE 框架是由 4 个英文单词的首字母组成，代表的意思分别是：

(R)each ：触达的广度。需求覆盖的用户广度，触达的用户数量或比例，在给定时间内影响多少产品用户。可以通过埋点获取指标、百度统计等系统来统计一段时间内的一些指标。

比如"每个季度影响多少客户"。例如项目 1：每月有 500 名客户到达注册漏斗中的此点，其中 30% 选择此选项。每季度覆盖率为 500 × 30% × 3 = 450 名客户

(I)mpact ：影响的深度。需求对每个用户影响的深度。比如 "当客户使用该功能时，该功能将提高多少转化率？20% 提高到了 27% 吗？"。这个指标很难准确评估，这部分评估更加主观一些。

Intercom 对这种主观评估提供了一种评分方法，如下：

Intercom 用 3 - 0.25 的量表来评分：

3 表示 "影响力巨大"。

2 表示 "影响力高"。

1 表示 "影响力中等"。

0.5 表示 "影响力低"。

0.25 表示 "影响力最小"。

这些数字会乘以最终得分，以将其调高或调低。

(C)onfidence ：对需求的信心。表示产品经理对该功能或需求的实现难度和成功率的信心，更多是产品经理对需求和用户痛点的理解程度，对估算的信心水平，可以用百分比来表示。

Intercom 提供了一种量表来表示，如下：

用一个百分比量表来表示，避免决策困难

100% 表示 "高度信心"。如果有定量的数据支撑 Reach，定性的数据支撑 Impact，且开发评估了较准确的 Effort，那么 Confidence 就是 100%。

80% 表示 "中等"。有定量的数据支撑 Reach，开发也评估了 Effort，但是 Impact 没有数据支撑，那么 Confidence 就是 80%

50% 表示 "低"。有数据支撑，但是数据的可信度较低，Effort 的波动也可能较大，那么 Confidence 就是 50%.

低于这个数字就是 "完全不可能"。

请诚实地问自己：你的估计到底有多少信心支持？

(E)ffort ：工作量。研发的成本，表示开发该功能或需求所需的工作量和资源投入，多个团队合作的人，比如有市场、商务等，涉及团队越多成本越高。工作量预估不确定因素较多。有一些方法：比如人天来估算；以故事点来估算。

Intercom 是用人月来估算-即是一名团队成员一个月能完成的公工作。他坚持使用整数（或 0.5，用于一个月以下的工作），以保持粗略的估计。

Intercom 中关于 RICE 分数的计算：

Reach：这将影响多少人？（在规定的时间段内进行估算。）
Impact：这将对每个人产生多大影响？（巨大 = 3 倍，高 = 2 倍，中 = 1 倍，低 = 0.5 倍，最小 = 0.25 倍。）
Confidence：对需求成功的估算有多大信心？（高 = 100%，中 = 80%，低 = 50%。）
Effort：这将需要投入多少"人月"？（使用整数且最少半个月 - 不要陷入估算的泥潭。）