Scrum product backlog refinement

Posted 2023-05-09

参考技术A Scrum3355中5个活动有个非常重要的Sprint planning meeting，迭代计划会关系整个迭代团队对Sprint目标以及迭代用户故事的理解与承诺。在迭代计划会之前，Scrum团队经常会忽略一个非常重要的活动即Product backlog refinement，即迭代梳理会。

Scrum标准的5个活动中没有迭代梳理会，Product backlog refinement往往放在计划会里。但是对于刚开始转型敏捷的团队或者外部干系人（需求提出人）比较多以及技术性较强产品，建议需求梳理会与计划会分开，第一可以避免需求梳理放在计划会里，造成迭代计划会时间过长，团队开会疲劳；第二PO提前与外部干系人或者架构师梳理需求，确定一个技术上可实现并优先级明确的Sprint backlog item（SBI），为迭代计划会提供符合DOR的SBI。

DoR：Definition of Ready 的缩写，直接翻译为“就绪定义”。DoR是指一个需求能够被团队接受的标准，认为该需求已经准备就绪，并可以纳入到迭代看板中的“To do”状态，是需求准入的标准。DoR的价值，有效防止“低质量伪需求”流入研发侧，同时加强了PO对需求梳理，以及涉及多业务时需求依赖关系的明确。

举个栗子：某一个产品需求DOR：

1.以用户故事为维度、业务逻辑、验收标准清晰

2.有优先级

3.如有依赖，则第三方依赖需求实现时间明确

4.有业务期望上线时间，版本规划

5.原型图或者UI原型完整

PO根据市场价值从产品Product backlog选择符合团队速率的迭代用户故事，可以提前梳理用户故事的一些业务逻辑，便于梳理会上澄清。SM确定会议的时间和地点，一般建议早于迭代计划会2天进行梳理会，参会人员一般是PO，SA（系统架构师），产品负责人以及外部需求干系人。如果新的迭代里面有技术故事，建议提前让架构师输出技术方案，梳理会上与相关干系人评审技术方案，确定后纳入迭代。

PO讲解下个迭代要做的用户故事、业务逻辑和PO理解的用户故事优先级，澄清后产品负责人以及相关提出需求干系人对PO梳理的业务逻辑评审讨论，是否符合需求，以及用户故事优先级是否正确，如达成一致后，则架构师提前考虑用户故事技术难度。如果迭代中有技术故事，则架构师需把技术实现方案比如数据模型设计与相关干系人评审。会议最后输出一个明确优先级以及业务逻辑明确，技术可实现的SBI。

梳理会后，PO根据讨论的结果整理Sprint backlog item，为迭代计划会做好准备。

产品项目中经常听到PO反馈自己梳理了一个用户故事，Scrum Team反馈技术实现难度大，需要2-3个迭代才能完成，导致PO对用户或者市场的承诺变动，所以Product backlog refinement不仅能够确定用户故事优先级、需求业务逻辑，也能提前识别技术实现难点，更有策略性的进行迭代计划安排。

Scrum迭代计划会

 Scrum迭代计划会怎么开

Scrum迭代计划会是Scrum最重要的会议，标志着迭代的开始，以及团队对用户故事的承诺。

在Sprint第一天上午召开Sprint planning meeting，这个会议分为两部分，计划会议上部分由PO、SM和Team参加，主要是PO从产品backlog中挑选出需要放到当前Sprint冲刺的产品Backlog即Sprint backlog item，讲解用户故事；会议下半部分由SM组织Team将SBI拆分成任务进行估算，PO也可以一起参加了解具体的开发细节以及随时解答团队对用户故事的理解。

计划会前准备

PO根据迭代计划会前的Product backlog refinement会议输出一个符合DOR的Sprint用户故事，DoR：Definition of Ready 的缩写，字面翻译“就绪定义”。目前本人参与的项目，团队达成一致，迭代用户故事DOR包括：1.用户故事介绍包括业务逻辑、验收标准；2.有优先级；3.有第三方依赖实现依赖功能时间明确；4.原型图完整。PO在梳理迭代SBI只有符合DOR才会被团队接受。用户故事的描述最好可以结构化，便于Scrum团队在迭代中协同。

SM需要在计划会前发出计划会公告，包括参会人、时间、地点、会议议程等。

计划会

计划会会议流程：

• 回顾上个迭代是否有遗留未完成的用户故事，PO决定是否放在本次迭代冲刺内

• PO讲解本次迭代目标，逐个讲解用户故事需求

• 开发人员理解需求并提问，PO回答问题，理解清楚后开发团队分解子任务并对子任务做估时或者故事点估算

• SM 记录子任务分解情况和估时情况。

如果前一个Sprint关闭迭代看板时候，会有个别上个迭代优先级低的用户故事团队未承诺完成的，PO首先要分析这些用户故事在本次迭代中优先级以及业务价值，决定是否放在本次迭代中优先冲刺还是先放在backlog中后续在完成。

PO讲解目标以及用户故事，团队达成共识后开始拆解子任务并对子任务预估时或者故事点估算，SM记录大家估算结果，分析估算情况与团队速率是否匹配。

计划会后

SM协助团队创建信息辐射器，把本次迭代冲刺的用户故事以及子任务录入到电子看板或者物理看板，同时发出本次迭代的冲刺目标、本次冲刺预估工作量和完成情况预测、潜在风险分析、本次迭代改进措施（源于上个迭代回顾会）。

迭代开始后，SM协助团队处理迭代中的障碍，组织站会，监控进度与风险。

— THE END —

写文章的坚持，更需要您的一个肯定

欢迎关注PM日常