产品待办列表梳理(PBR)是什么？

产品待办列表(PBL)是Scrum框架下最重要的一个工件(Artifact)，产品待办列表的梳理(Product backlog Refinement-PBR)也是一个重要的活动，它不同于Scrum的3-3-5-5。仔细阅读Scrum指南，对产品待办列表梳理活动的描述是有限的：

“只有那些Scrum团队可以在一个Sprint中完成的产品待办事项，才能作为Sprint计划会议中的准备就绪事项。这种透明度通常需要通过“产品待办列表梳理”活动来获得。产品待办列表梳理是将产品待办事项进行拆分，并进一步梳理为更小更精确的事项。这是一项持续不断的活动，用来为产品待办事项补充细节，包括细节描述，排序和评估大小等。添加的细节属性通常随工作领域的不同而变化。”

在CSM的培训中，我发现有时学员把PBR活动与Sprint计划会议混为一谈，在Sprint计划会议上做产品待办列表梳理。有时把产品待办列表的梳理说成是Sprint Backlog的梳理。借机来写一篇文章，“梳理”一下产品待办列表梳理活动的概念。结合多年教学咨询的经验，与国际敏捷专家在敏捷社区的切磋，分享我理解的PBR的具体做法和常见误区，对Scrum指南的PBR部分也是一个补充和解读。

1. 为什么要做产品待办列表梳理PBR？（why）

我们承认对于敏捷项目或产品，需求是一个渐进明细的过程，过早的锁定范围和细化需求是不明智的。所以，需求的梳理是一个持续的活动，一个just in time的规划过程。即每个迭代的过程中，开发团队除了围绕Sprint的目标，按照Sprint Backlog(SBL)的计划尽力实现承诺的产品待办条目(Product backlog Item - PBI)之外，还要抽出一部分时间来协助PO梳理需求，确保下一个迭代计划会议的需求是就绪的(ready)。这样做的目的，增加了Sprint计划会议团队承诺的信心指数，大大降低了交付的风险。

那么问题来了，准备多少个PBI和PBI梳理到什么程度算是比较合适呢？一般情况下，我们建议准备1-2个Sprint的需求，最多不要超过3个Sprint的内容, 采取刚刚好(just enough)的策略。试想一下，只准备一个迭代的需求可能不够，另外PBL的优先级可能会发生变化，所以稍微多准备一些。但梳理太多会造成不必要的浪费，因为情况总是在发生变化。产品待办列表的梳理活动上，团队不会承诺下一个Sprint做多少。

有什么样的原则能够指导PBL梳理就绪？

产品待办列表PBL满足“DEEP”的特征。通常我们用DEEP来体检PBL的健康状态。

D: 需求的颗粒度有不同的层级，优先级高的需求细化。

E: 估算PBI的成本大小。

E: 拥抱需求变化，新的涌现出来的需求，以PBI的形式添加在PBL中。

P: 排优先级，即排序。

对于PBI的就绪，主要满足大家熟悉的INVEST的原则(见下图对INVEST的解释)，Scrum的模式语言Definition of Ready(DoR)对我们的实践指导是有效的，尽管DoR不是Scrum的核心内容，但会帮助我们理解PBR活动的重要性。定义DoR的维度，除了INVEST以外，还考虑：提前识别技术难点(spike)；依赖关系；UI/UX的设计工作；合规和法律认证的事宜。一个DoR的例子如下：

2. PBR活动包括什么具体内容（what）

主要包括：

对PBI的业务价值和验收标准的澄清，讨论足够的细节，包括新近加入PBL的优先级高的需求条目。
大的需求(Epic)的拆分(breakdown)，注意是对PBI的拆分，不是传统的任务分解(WBS)。如果PBI的优先级很高，要拆到这个PBI能够fit到Sprint中，不同PBI拆分有不同的策略，这里不再叙述。
估算，有时也叫Sizing，总之是估PBI的effort。敏捷推荐相对估算。建议对所有的PBI都要给出估算(如果可能的话)，注意这里不是指SBL的条目SBI，任务的估算。
对PBL的重新排优先级，PO会按自己的价值方法对PBL的排序，在PBR活动中，开发团队协助PO审视PBL优先级的合理性，比如涉及PBI之间的技术依赖或资源约束条件等，重新排优先级。
另一个最重要的动作，看看哪些需求没有价值，不合理，从PBL删除，保证PBL的健康度(good shape)，有时用邓巴数(150定律)作为参考PBI的个数。

Scrum框架中设计的持续进行的产品待办列表梳理活动(PBR)是一个落地的“对话”实践。研发和业务人员以对话为核心，采用不同的技术和工具，补充丰富并完善细化PBL。敏捷团队的具体实践有：交互式原型(UI prototype)，线框图，视觉模型，流程图(flow chart)，Mockup，Wiki Page形式支持文档，简短的讨论文案，包括算法和技术要点等等，都是进一步细化需求的手段。

有人会问，PBI的大小就绪(ready)有什么特征或指导，这里有三个原则供参考：

1/2原则：一个PBI或用户故事(user story)满足sprinting-able，假如由一个开发人员搞定这个PBI，不应该超过Sprint长度的1/2的时间。
1/4 原则：一个PBI的大小，团队去实现它，不要超过Sprint长度的1/4时间。
用户故事点8：大于8个点的用户故事，给我们一个信号，需要拆分。具体实践下来，团队会找到大家认可的基准和公用尺码，比如2个点的用户故事意谓着多大的工作量。

3. 谁来参加PBR（who）？

我们强调全员都参加(inclusive)，即整个Scrum团队，PBR活动会增加成员的参与感(engagement)。工作坊的形式很重要，用户故事卡片会自然引发对话。

不像传统的做法，只有少部分人员或资深的工程师参加。全员参加的好处，保证PO与开发团队面对面沟通，通过对话的形式理解业务需求，信息对称。有时候PO会邀请关键的干系人(key stakeholders)参加；特别是需求的提出方，或是Feature Owner。Scrum鼓励开发团队与用户的直接沟通，而不是所有的信息都要通过PO，PO不是中间人(middle man)。这种对话SM可充当引导者，保证沟通高效，PO或客户直接澄清需求给团队。

这样做，也许会有人担心：

（1）业务担心需求“失控”，开发团队会对客户承诺太多。有时候我们担心研发搞砸(mess-up)，嫌麻烦，所以会找个借口，比如开发人员驾驭客户的能力不够，演讲(Presentation)能力不“专业”，不邀请他们参加此种会议或对话，图省事。其实，让真正“干活”的人第一时间理解为什么要做这件事情比如何做更要紧。把团队封闭管控起来，不允许与客户用户直接沟通，潜在的风险更大。把“正确”的需求做“对”，是我们的共同目标，PO可以在这个“对话”过程中充当引导者的角色，便于管理。

（2）干系人(包括sponsor和管理者)平时很忙，没有时间参加此类PBR的活动。每次PBR的活动，PO有责任邀请相关的干系人参加。具体的做法，PBR活动提前在Scrum日历上固定下来，让需求相关的干系人可以分时段参加PBR，不需要干系人全程都参加PBR。合理分配好时间，通过面对面的对话，对需求的充分理解，是把事情做对的关键一步。

你会发现，Scrum设计的PBR活动，从某种角度解释，它把敏捷原则的第四条“项目过程日常工作中，业务人员与开发人员必须在一起工作”实实在在的落地了，业务和研发的“协作”变成了具体可操作的“动作”。

4. 什么时候做？(when) 做多长时间？（how long）

PBR是一个持续的活动，一个不好的消息是，Scrum没有特别“告诉”你什么时候做PBR。推荐的做法：在Scrum的日历上以工作坊(workshop)的形式把它固定下来，有些团队叫Backlog Grooming，比如一个Scrum团队提早约定好在两周迭代的第二周的周二下午3点到4点半做PBR，届时大家都会出席, 当然PO要做好充分的准备。Scrum建议开发团队在每个迭代过程中投资团队容量(capacity)的5-10%时间协助PO梳理PBL，注意5-10%是一个累加总值，PBR可以在迭代中做多次，有时是估算，有时是拆分，也可能是估算和拆分的混合。

根据我的观察，PBR的活动分布在Sprint过程中的以下时段:

A. PBR在Sprint 1之前的发布(版本)规划中或follow-up session，保证第一个Sprint的需求就绪(ready)。

B. 在Sprint过程中安排每周一次或每个迭代一次的梳理活动，时间固定下来，不需要有专人协调时间。

C. 每日站会结束后，安排单独的小块时间梳理部分需求，特别是分布式团队，PO和团队不在同一地方。考虑到时差和异地的影响因素，不用再单独协调大家PBR时间。

D. Sprint评审会结束之前，留出一部分时间来一起看看未来的1-3个Sprint要做什么，基于评审会的反馈调整PBL，影响到发布计划。好处是干系人正好在现场，不需要单独邀请，节约时间，而且评审会刚刚开完，趁热打铁。不好的地方是离下一个Sprint计划会议太近，有些匆忙，而且评审会已经消耗了能量，需要休整。

最后，期待这篇文章对产品待办列表梳理PBR的困惑有所解答。如果能参加CSM/CSPO课程，你将体验到产品待办列表梳理各项活动：PBI的进一步澄清(业务价值和满意条件)，估算，拆分，排优先级的技术和实践。

Jim Wang王军

写于2022年12月5日

参考资料：

（1） CSPO 教材

（2） Scrum 指南

（3）《Scrum Essential》 By Ken Rubin

产品待办列表梳理(PBR)是什么？相关推荐

谁负责Scrum 中的产品待办列表?
Product Backlog (产品待办列表) 是所有你所产品的需要 (Product requirements) 以及产品需求变化 (new product requirements) 的唯一来源 ...
产品待办列表如何精化？
Scrum中安排了精化活动,早期版本的英文是Grooming, 现在是Refinement,原来翻译为细化,最新版Scrum Guide中文版采用了"精化".最新Scrum是这 ...
产品待办列表的几个最佳实践
产品待办列表是什么产品待办列表对应的英文是project backlog,也有翻译为"产品待办事项列表",是指为开发完善产品而待办的事项列表. 在Scrum Guide中,产品待 ...
敏捷CSM认证:SCRUM 工件之产品待办列表
敏捷CSM认证:SCRUM 工件之产品待办列表 Scrum 的工件以不同的方式表现工作任务和价值,可以用来提供透明以及检视和适应的机会. Scrum 所定义的工件是特别地设计的,是为了给关键信息提供最 ...
产品经理规划产品之需求梳理
业务需求.用户需求和功能需求这三个概念,对于产品新人来说,经常容易混淆,但了解这些是身为产品经理的一个基本功. 问:业务需求对于产品经理来说很重要么? 答:业务真的是很重要.并不是说功能逻辑和交互不够 ...
axure按钮切换颜色_如何用Axure画出Web产品的列表组件：基础画法
Web产品的列表组件在画原型的时候比较常见,所以PM有必要深入了解它的各种交互效果和对应的原型画法. 除了通过表格来画出简单列表之外,我们还可以通过中继器来画出列表,相应的原型效果请查看https:/ ...
树型列表结构宽度调整_如何用Axure画出Web产品的列表组件：基础画法
Web产品的列表组件在画原型的时候比较常见,所以PM有必要深入了解它的各种交互效果和对应的原型画法. 除了通过表格来画出简单列表之外,我们还可以通过中继器来画出列表,相应的原型效果请查看https:/ ...
VMware 兼容性列表与产品互操作性列表使用收集（持续更新中...）
目录一.VMware 兼容性列表查询查询网址: 查询例子1:服务器CPU兼容性查询二.vSAN兼容性查询查询网址: 查询例子1:vSAN认证的RAID卡兼容性三.VMware 产品互操作性列 ...
《人人都是产品经理》一书作者推荐的国内产品书籍列表
<人人都是产品经理>一书作者推荐的国内产品书籍列表

产品待办列表梳理(PBR)是什么？

产品待办列表梳理(PBR)是什么？相关推荐

最新文章

热门文章