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 不仅能够确定用户故事优先级, 需求业务逻辑, 也能提前识别技术实现难点, 更有策略性的进行迭代计划安排.
来源: http://www.jianshu.com/p/e6c6b80c283f