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