计划会作为Scrum常见的活动之一，相信大家都十分熟悉了，我们也经常看到各项目组开计划会的流程: 会议前PO准备好用户故事及验收准则，在计划会议中现对各用户故事进行澄清，并对验收准则进行说明，待团队成员对每个用户故事都理解后进行估算工作，然后是领取任务，最后共同表示信心值。在这种类似的模板中，使我对产品待办列表梳理和计划会的理解出现了偏差，认为产品待办列表梳理活动就是PO一个人的事情，估算也就是应该在计划会议上做的，在最近阅读的《敏捷革命》和《Ｓｃｒｕｍ精髓》，与我的理解出现了冲突，很是困惑，潜意识里还是想要找到一个标准的答案，最后在王老师的帮助下，疑惑得到了解答，下面我将对王老师的答案和自己的理解做一个简单的分享，欢迎大家一起讨论。
产品待办列表梳理活动是由PO 负责的，这话没错。PO 可以是一个人，也可以是一个小团队，根据PO 的需求可以involve不同的角色来协助他完成这个活动需要做的工作或给出相应的建议，梳理活动不是PO 一个人或PO 团队的事，团队至少应该留出10%的时间协助产品负责人梳理（写、优化、估算和排序每个PBI）产品列表，帮助确保PBI达到就绪状态。――――――摘自《Scrum精髓－冲刺规划》
产品待办列表梳理活动主要是为了解决以下４个问题：
１、需求的讨论，用户故事的拆分、澄清
２、 完善验收的标准
３、 对故事的优先级进行排序
４、 故事的估算（估算推荐采用斐波那契数列）
计划会主要是依赖于会议前梳理好的产品列表（大小合适、经过估算且有顺序）
１、 根据团队可用的生产能力，决定当前迭代需要完成哪些故事
２、 根据实际情况看是否有必要对故事进行Task 拆分（与故事相关的开发性事务和非开发性事务）
３、 分解任务后大家自由领取Task ，并做工时的估算（Task 的复杂度在梳理活动中大家有共识）
４、预测承诺能完成哪些故事，共同表示信心值
在这里我们看到，梳理活动的很多项在我们实际项目实践过程中与计划会议就一起做了，所以我们经常在计划会中会看到计划会议时间过长或无法准时开始迭代的情况。
Scrum知识约束了Planning会议的产出，但实际在操作的时候，如果把所有的事情都在会议上从头进行，对于不成熟的敏捷团队会很没效率，所以要提前准备，让会议更有效率的产出。至于会前怎么准备，Scrum并没有约束，所以这就留给实践的人一定的空间，去探索更适合自己的上下文的准备实践了。――――――摘自王维老师
因此在指导某个项目组开计划会时，在不违背计划会原则的前提下，尽可能避免套用模板，结合项目组当下的实际情况去探索一场适合自身的计划会。
