Scrum product backlog refinement

Posted PM日常

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Scrum product backlog refinement相关的知识,希望对你有一定的参考价值。


Scrum product backlog refinement

Scrum product backlog refinement

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:

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

  • 有优先级

  • 如有依赖,则第三方依赖需求实现时间明确

  • 有业务期望上线时间,版本规划

  • 原型图或者UI原型

梳理会前


Scrum product backlog refinement

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

梳理会中


Scrum product backlog refinement

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

梳理会后


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


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

— THE END —





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

欢迎关注PM日常








以上是关于Scrum product backlog refinement的主要内容,如果未能解决你的问题,请参考以下文章

Scrum Product Backlog 产品待办清单

软件测试敏捷开发

如何看待Scrum Sprint Backlog冻结和变化?

白话SCRUM 之三:sprint backlog

简述scrum过程

微软Team Foundation Service 的Scrum模板中的Feature和Backlog Items 的区别转载