本文是敏捷开发产品管理系列的第五篇。（序言及设立迭代目标，产品版本规划，产品用户群规划，新产品研发，预估会议，Product Servant，Product Owner团队，产品线管理）

粗估会议是一个较少使用的敏捷实践，但其作用还是很明显的。

Why

Scrum里边，有两个关于需求的比较头疼的问题。

一个是PO不太懂技术，不知道故事大约需要多久才能完成。为什么PO要知道？因为如果划分的颗粒度不好，会导致有的故事太大或太小；而且如果不知道故事的大小，就比较难大致预测未来的几个迭代能做完哪些故事，版本计划不好做。

二个是如果只依赖短暂的Sprint Planning Meeing，往往团队对故事的理解不够深刻。人的思维方式往往是分为两种的：一种是集中思维，就是现场的讲解问答；另一种则是分散的思维，就是“回去以后越想越不对劲”的那种，后者如何利用呢？

开一个预估会议把。

When

有一家游戏公司，会在每次Sprint Planning Meeting前一天，先把整个迭代要开发的大致内容讲解一下。这次讲解，未必是按照故事条目来的，更多的是整体的介绍。因为游戏的需求相对复杂，而且关联关系很重，所以有必要整体把握以下。这很像拍摄电影，导演会把下一个场景整体介绍一下，才会分解镜头拍摄，否则整体感和连贯感会很差。

有一个日本企业，则是在30天迭代的第10天左右，开下一个迭代的预估会（或称为预测会也行），整体就是提前20天介绍一下下个月有什么事情要做。这个目的，则是让队员在剩下的20天里边，都会潜移默化地思考下个月的事情；另外就是在开发本月内容的时候，如果成本很低，会提前做一些准备工作（比如预留点接口。“过度设计”很容易造成浪费应该避免，但是为20天后的工作内容做准备，则极少会浪费，所以值得）。

How

在预估会上，PO给大家讲解整体需求，和他对下个迭代的期望，以及他提前拆分出来的几大块或几小块内容（看工作习惯了）。

团队会分析这些内容的关联性、实际工作内容、工作量规模等内容，必要时拆分故事，描述故事的依赖性，并进一步帮助PO形成条目化的用户故事。

PO在形成有工作量预估的用户故事后，会重新计算和规划下一个迭代的工作内容，让其能更完整地组成一个发布。

当然这次估算不一定准确，力求做到条目化和拆分即可，准确性由参会者在直觉上保证都可以，毕竟在计划会上还会细化。

Who

有时候整个团队参加，尤其那些对完整性要求比较高的产品，比如游戏。

有时候只让小组长或骨干参加，他们会把参会的内容传达给自己的队员；更少的参会人员，可以降低对其他无关人员的工作量占用影响。

这取决于产品和团队的情况，试着开几次会议，自然会发现怎样才是合适的。

TODO

PO开完会议后，可能有这样一些工作要做：

1. 记录下来最终被条目化的故事。

2. 在计划会之前，把会议上似是而非的一些内容敲定。

3. 根据故事的大致规模，规划下一个迭代的内容。应本着相对完整内聚的原则，组织成一个用户能真正拿到并完整工作的产品。

4. 按照MoSCoW排序出下个迭代的内容。（MoSCoW请参考http://cheny.blog.51cto.com/3988930/1100076 ）