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：

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每日站会

国内的有阿里巴巴的一个工具，叫云效，可以支持需求、缺陷、项目管理到DevOps的一站式管理，功能也比较齐全, 有里程碑、看板、迭代等！上几张图看看效果吧！

1、里程碑计划功能让项目管理者清晰定义项目目标和任务，并对项目里程碑计划进行实时监控。

2、迭代是敏捷开发的概念，它是有开始和结束时间的轻量级计划，用来明确规划在开始和结束时间之间需要实现的需求、需要修复的缺陷和需要完成的任务。一个典型迭代的周期从1到6周不等，团队可根据自己的节奏或业务的需要来确定迭代周期。

以典型的Scrum为例，迭代规划的具体流程为：

用户和业务方提出的需求和缺陷，由Product Owner（产品负责人）来统一管理，经分析、评估、拆分和PK后，确定优先级，在计划会（排期会）上和ScrumMaster（迭代负责人）和研发团队进行排期，进入迭代

研发同学在迭代周期里面，对自己负责的需求进行任务拆分、拉代码变更分支，并且每天更新进度和状态

需求实现进行测试和验收后，进行发布，相关需求状态自动设为完成

迭代完成后，如果有未完成的工作，移到下一个迭代

工作项管理

风险管理

Scrum有个每日检视的会议即每日站会，目的是要进行集中检查团队在Sprint中的进度如何。在会议中，团队成员能够很容易地提出当前遇到的问题，然后可以马上讨论合适的解决方案。如果15分钟会议内无法讨论出解决方案，则会后相关人员继续小范围讨论解决方案。

每日站会通过互相共享任务进度，使团队成员之间提高合作度，从而提供成员之间互相帮助的机会。在这种极高的透明度之下，Product Owner和Scrum?master就能够很容易地了解项目进度和用户故事的完成情况，以及Scrummaster通过站会了解团队存在的障碍，并协助团队解决，最终让团队完成迭代目标。

疫情期间部分同事在现场办公部分同事可能远程办公，那Scrum中每日站会怎么开展，是每个Scrum master面临的问题。下面分享一下本人在项目中的一些实践。也欢迎其他不同的实践方法交流。

团队选择每天固定时间9点半开团队站会，现场办公的同事选择一个固定的地点开站会，远程的成员通过远程会议（比如腾讯会议）加入。为了站会效果，选择了一个带有电视的会议室，一是团队成员可以面对面围着会议室桌子站立，二是通过电视投屏可以让团队成员聚焦迭代Kanban用户故事。因为采用2周一个迭代，迭代第一天上午计划会以及迭代最后一天下午要进行演示会和回顾会所以不开站会，即一个迭代10个工作日中有8个冲刺日进行每日站会

按 照事前事中事后的思路，站会前 Scrum master通过项目管理系统分析Sprint迭代看板，提前识别迭代潜在风险和问题：

站会中 ，Scrum Master主要职责维护敏捷站会规则，辅助开发团队自组织轮流发言三句话，协助团队解决站会提出的问题并记录待办事项。

站会后 ，Scrum Master整理站会上团队成员遗留的站会问题，发到项目内部沟通群，提示团队成员解决，并持续跟进。

第一指导原则：主题明确，不要讨论其他无关的话题

第二指导原则：站立会议允许“猪”角色说话，“鸡”不能讲话（Scrum猪跟鸡的故事）

第三指导原则：所有人站立围成一圈

第四指导原则：确保整个团队成员都要参加每日Scrum会议

第五指导原则：每日Scrum站会会议是团队交流会议，不是报告会议

第六指导原则：每日Scrum站立会议应该控制在15分钟以内

第七指导原则：Scrum站立会议要在每日同一时间，同一个地点举行

鹏仔微信 15129739599 鹏仔QQ344225443 鹏仔前端 pjxi.com 共享博客 sharedbk.com