产品待办列表梳理(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