需求梳理会（Product Backlog Refinement Meeting）在Scrum框架中都没有正式的“名份”，只是在2020年《Scrum指南》的Product backlog中有提及：“Product Backlog Refinement是将 Product Backlog 条目分解并进一步定义为更小更精确的行为。这是一项持续进行的活动，为Product Backlog 条目增添细节，例如描述、优先顺序和规模”，不过在Scrum Alliance官网上对 Product Backlog Refinement有更详细的描述。（https://resources.scrumalliance.org/Article/product-backlog-refinement）
需求梳理会作为正式迭代开始前的准备仪式，对迭代成功与否起到关键作用，所以即使“名份”不高，但是我们必须十分重视，这里我们为大家总结了一份需求梳理会的最佳实践干货集，希望能对你的需求梳理会有所启发，大家也可以根据团队的实际情况进行调整运用。
一、认知层面的干货
在进入需求梳理会实践层面之前，有些意识层面的干货必须对齐一下，需求梳理会是PO和团队一起梳理下个迭代Backlog的过程，其目标是为了提升迭代计划会的效率，促进迭代目标的达成，是整个Scrum Team协作、共担职责的重要机会。大家也可以反方面对齐一下：
1) 需求梳理会不是需求进度汇报会
2)需求梳理会不是需求讨论会
3) 需求梳理会不是任务分解会（怎么实现）
4) 需求梳理会不是需求交接会
二、操作层面的干货
| 维度 | 内容 |
|
|
对接下来的Sprint的Backlog进行细化、讨论、初步估算和优先级排序，以为下个Sprint的规划做准备。 |
|
|
在下个Sprint计划会议前三个工作日，必须完成下个Sprint的Backlog梳理。 |
|
|
1. PO讲解需求背景、价值，下次Sprint的初步计划目标 2. PO介绍每条需求，团队讨论、提问，PO解答、优先级 3. PO和团队一起对用户故事进行初步估算，如果规模比较大（超出要求），则继续分解 4. 团队和PO一起初步确定用户故事的验收标准，以及选择下一个迭代初步可以完成的用户故事 |
|
|
1.梳理后的Product Backlog 2.行动项 |
|
|
最长 90分钟 |
|
|
PO、团队（包括开发、测试等）、SM 、（相关干系人，如：业务、管理需求提出者、非功能需求提出者） |
1）准备
继续干货，为了高效召开需求梳理会，Scrum Team需要有充分的准备，特别是PO，当然团队和SM需要准备，如下是一个实践样例：
|
|
需要准备的内容 | 主体 |
|
|
PO在需求梳理会之前已经筛选出需要初步沟通（梳理）的需求列表（Product Backlog Item）这些需求是可以在下一次迭代中完成的需求 （所以PO需要参考历史数据进行初步估算），可以适当多一点（如：团队速率的1.5倍） |
|
|
|
PO需要确保需要梳理的需求已经进入Leangoo中的迭代（并完成关联操作） |
|
|
|
每位成员提前观察Leangoo看板，初步了解本次需求梳理会的内容，并提前准备好问题 |
|
|
|
自我检查需求梳理会的准备情况（使用《需求梳理会准备情况检查表》） |
|
|
|
提前确认所有参会成员（如：开发、测试、UI等）的时间，并帮忙安排会议室、设备等 |
|
然而PO由于各种原因，可能对需求梳理会的准备还是不够充分，所以我们必须有更加明确的需求梳理会准入标准，如：通过如下检查表后方可召开需求梳理会：
| # | 需求梳理会会前检查项 | 说明 |
| 1 | 需求是否录入了Leangoo（需求、需求描述、验收标准）？ | 不要对着自己的Excel |
| 2 | Leangoo中的需求信息是否完整（需求提出人、需求描述、验收标准）？ | 可以使用附件等辅助说明 |
| 3 | Leangoo中的需求是否进行了估算（规模），优先级排序等？ | 需求粒度要小于3标准人天 |
| 4 | 计划需求的规模是否在下次迭代容量（团队可用容量）范围左右 | 提前了解概要了解（计算）团队的可用容量 |
| 5 | 是否初步维护了迭代目标？ | 不要仅仅是功能的罗列，要突出重点 |
| 6 | 是否准备了用户画像/用户旅程图/同情图/流程图/数据流图等辅助说明工具？ | 不要对着空气讲，要对着可视化的图形讲解，提升需求沟通效率和效果 |
| 7 | 是否准备了相关案例/例子/样例？ | 不要现场再想，再临时整理思路 |
| 8 | 本次需求相关文档（用户画像/用户旅程图/同情图/流程图/数据流图）是否已经发给（或上传）组员？ | 提醒大家提前看，并准备问题 |
2）执行
一旦开始执行需求梳理会，对会议的管理就尤其重要的了，直接上干货：某公司的需求梳理会议程安排
| # |
需求梳理会执行过程中的检查项 | 说明 |
| 1 | 是否有抽部分人员进行反讲？ | 确认大家是否明白、理解，进行对齐 必要时进行点名互动 |
| 2 | 是否有进行板书？ | 解释流程图、算法等，或展示提前准备好的材料 |
| 3 | 是否有记录问题（行动项）？ | 不能仅仅靠脑子记 |
| 4 | 是否有人一直没有发言/提问？ | 要关注所有人的参与，一个不能少，要充分对齐 |
| 5 | 是否有初步决定进入迭代的需求？ | 面对不进入下次迭代的需求，不要化超过5分钟的时间讨论（浪费时间） |
| 6 | 是否每条需求都有了初步的验收标准？ | 开发、测试等团队成员都需要提出验收标准 |
三、实践技巧干货
当然在需求梳理会的操作实践过程中还有很多技巧值得借鉴,这些实践技巧可以进一步保证需求梳理会的沟通效率和效果、参与度、幸福指数等。
1）15/5原则
每个需求（PBI）讨论15分钟，如果超过15分钟则记录问题（行动项），PO会后再充分准备材料，如果有新的想法出现或后续迭代需求，最多只花5分钟进行初步对齐。
2）0.5/3 法则
所有需求必须进行分解，分解颗粒度最小0.5标准人天，最大3标准人天。这样做的好处是充分理解需求（如果需求不能拆分，证明我们没有理解需求），同时也有利于后续需求的实现跟踪（可以每天有价值交付）。
3）预留需求梳理会的时间
在迭代计划会中预留需求梳理会的工作量，比如：每个迭代5～10%左右的时间，让需求梳理会合法化，有时间有空间，成为一个必然的、自然的迭代活动。而不是每次需求梳理会都是挤时间，或看情况再实施。
4）多次需求梳理会
可以把需求梳理会分为多次召开，每次都有严格的时间盒，小批量。每次需求梳理会时间最长不建议超过90分钟（建立分两次，如：每次50分钟），每次只讨论符合需求梳理会入口标准的Backlog。
5）会前准备问题
制定需求梳理会的Agenda，并提前把需求梳理会需要讨论的内容发给参与者，同时要求参会者提前准备至少3个问题/每人，或3个需求的讲解准备。需求梳理会前严格检查各个入口标准，从会议设施到人员安排，从会议议程到Backlog质量标准等等。
四、常见问题干货
1）Backlog是PO的职责，为什么不能PO自己梳理清楚需求，再讲给团队听呢？
需求梳理会一个很重要的作用就是让团队尽早接触到需求，如果等PO把需求全部“写”出来估计需求自身的价值会减少，需求实现的时间更会被无情压缩，所以需求梳理会中的用户故事是用于对话的需求呈现方式，当然为了保证对话的高效，PO确实需要做大量准备，能做到有问必答，有答即决策，而不是讲不清楚，一问三不知。
如果您想了解一下自己或团队是否真正理解需求梳理会，您或您的团队也可以参扫描如下二维码进行自测，预祝您通过测试。完成测试的小伙伴，欢迎根据指引加入Scrum中文网敏捷武林交流群，和更多群友切磋敏捷武艺。
需求梳理会小测验
作者：王庆付博士
-
Scrum中文网首席敏捷教练 - SAFe官方国际授权讲师，国内交付SAFe培训和咨询最多SPC之一
- 资深大规模敏捷教练，CSP，DevOps Master
- 业务敏捷专家Agile Business Professor
- China SAFe Day的发起人，核心组织者和Keynote演讲者
