需求梳理会(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演讲者