谈谈Backlog梳理活动

刚开始尝试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中文网资深敏捷顾问 

本文转载自：敏捷工具Leangoo.com