刚开始尝试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决定即可，不需要其他人参与。
- 之所以放在第⑤步，是因为排优先级时要考虑用户故事的规模、技术上的依赖关系和技术风险。
本文转载自：Leangoo.com