刚开始尝试Scrum的团队,往往都会碰到一个问题,那就是Sprint计划会议的开会时间过长。笔者就曾经见过这样一种情况:为期两周的冲刺,Sprint计划会议足足开了一整天,白天开不完,晚上加班接着开。
那么为什么会出现这种情况呢?时间都主要消耗在哪里?通过观察,笔者发现大部分时间都消耗在对用户故事的讨论上,具体来说就是对用户故事的业务、界面和交互,以及技术实现方案和测试要点的讨论。
在业界谈起Scrum时,往往都只会提到“343”,即——3个角色、4个活动和3个产物。但是在实践中,我们发现还需要引入另外一个活动,那就是Backlog梳理活动。如果没有引入Backlog梳理活动,那么Sprint计划会议往往会严重超时,而在引入Backlog梳理活动后,Sprint计划会议往往能够控制在时间盒内结束。
什么是Backlog梳理活动?
Backlog梳理活动,是在下个冲刺开始前,对可能要纳入到冲刺中的故事进行细化、估算和优先级排序的活动。
谁参与Backlog梳理活动?
PO、SM和团队都应当参与,其中SM是活动的组织者。
什么时候开展Backlog梳理活动?
在本冲刺中要完成下个冲刺的Backlog梳理,确保下个冲刺的故事在Sprint计划会议启动前要符合INVEST原则。
在实践中,我们发现Backlog梳理过程中往往会碰到无法当场确定的问题,所以不能指望通过一次开会来完成Backlog梳理,更好的做法是每天都花一些时间来做Backlog梳理。
如何开展Backlog梳理活动?
在实践中,我们整理出Backlog梳理五步法,具体如下:
① PO和团队一起讨论用户故事的背景、业务目标、用户角色、用户场景、业务流程、业务规则,保证团队理解充分并且无异议。
② PO和团队一起讨论界面和交互流程,画出低保真和交互流。
③ PO和团队讨论用户故事的测试要点、技术实现方案、可能存在的技术风险,必须输出测试要点(即验收标准),测试要点形式不限(建议直接写在故事卡的背面,这样方便查看)。
- 其中可以分为以下三个过程:
1)PO与一个资深测试人员讨论和整理出测试要点。
2)PO与整个开发团队交流用户故事的测试要点。
3)开发团队讨论初步技术实现方案、技术风险。
- 其中的注意事项:
1)要先准备好测试要点,避免一群人坐在一起从0开始整理。
2)讨论初步技术实现方案的目的是为了做估算、识别技术依赖以及技术风险,详细的技术实现方案应该留到冲刺开发时再讨论。
④ 团队估算出用户故事的规模(故事点数),对于过大的用户故事要拆分成小故事。
- 其中包括以下过程:
1)PO先与SM,对用户故事做初步估算以及拆分,以便进行下一个发布版本的冲刺规划。
2)对于下一个冲刺要用的故事,SM组织开发人员估算出开发规模,组织测试人员估算出测试规模,再集中整合。
- 其中的注意事项:
1)为了做发布版本的冲刺规划,需要进行初始估算,这个活动不需要整个开发团队都参与,只需要少数核心人员参与。
⑤ PO对用户故事排优先级。(在产品Backlog中建立用户故事卡,顺序即优先级)
- 排优先级只需要PO决定即可,不需要其他人参与。
- 之所以放在第⑤步,是因为排优先级时要考虑用户故事的规模、技术上的依赖关系和技术风险。
本文作者:
李洁(Jerry Li) ,Scrum中文网资深顾问,CSM,敏捷教练