http://www.cnblogs.com/enze/archive/2012/08/13/2635658.html
１.迭代计划会在每个迭代的第一天召开，目的是选择和评估本次迭代的工作项。
２.产品负责人逐条讲解最重要的产品功能。
３．开发团队共同估算故事所需的工作量。直到本次迭代的工作量达到饱和。
４.产品负责人参与讨论并回答与需求相关的问题，但不干涉估算结果。
产品负责人准备什么？讲什么？
准备工作：条目化需求(用户故事)、优先级排序、最近1~2个迭代最想看到的功能。会前的准备工作十分重要，可以帮助产品负责人清理头绪，不至于在迭代期内频繁提出变更、增加、修改故事。
会议讲解：难以用文字描述的内容。在讲解的过程中，团队可以随时提问，产品负责人要给予解答。若产品负责人感觉暂时无法讲解清楚，可以推迟此故事的开发，或将故事分解为"已想清楚"和"未想清楚"，后者推迟到下一个迭代或更晚。
一瓣地，一个团队只有70%的工作可以进行正常工作，因此，每个人月安排15天左右即为饱和，新团队则最低10人天左右。
团队怎么估算？
1.共同估算：在估算前不应该指派由谁开发某个故事，而是以接受故事的小组为单位集体估算，每个人提出自己的看法，大家综合，这样才能以集体的智慧完成任务。
2.在估算全过程，产品负责人不能离开，因为很多估算差异问题来自于"做什么，做到什么程度"，产品负责人需要给予解答，而不是让团队自己理解去做。
3.共同估算为的不是一个数字上的统一，为的是用集体的智慧和只是对"做什么，怎么做"达成共识。
4.共同估算，是共同跟进的基础，若不能共同估算，则后面的【每日立会】几乎不可能正常进行，因为大家只会关心自己曾经一起分析、思考、提问、设计甚至争论过的任务的进展怎么样了。
5.共同估算的最佳方法是"扑克牌估算法"，这貌似很想个小游戏，但却是"Delphi"估算的一个快速的方法，同时实现了匿名性和高效性。
"扑克牌估算法",是几个潜在的任务承担者(比如某个功能小组)共同估算的方法，他们一起听产品负责人讲解，一起估算，以达到利用集体智慧解决问题的目的。
算法思想:每人各自估算后独立出暗牌，听口令一起出牌；然后进行数值大的跟数值小的进行PK，阐明各自的原因，其他成员旁听，也可以参与。讨论结束后，重新出牌、开牌。重复以上的过程，直到结果比较接近。
常见问题:(一个项目经理/小组长带新人的师徒制度中)
1.为什么任务要分给组而不是分给个人？
不分给个人，这样可以使得每一个人不得不全面考虑，对此有所了解，日后及时他不担当此模块，他对这个模块也有了解。
2.为什么不让最后领取任务的人估算？
因为他可能不知道某些代码的可用性、不知道某软件不可用、不同Template、......，从而选择了错误的实现方法。
3.为什么不让师傅估算,大家直接采纳呢?
师傅的想法通常是徒弟所理解不了的。共同估算就是让大家在思考中，对照自己的实现方法和师傅的差异的过程。
4.PO怎么还参加？不是不让别人参与吗？
PO可以挑战估算，比如"这需要那么久吗"，但是要有理有据。其实实践中更容易看到的是团队往往过于乐观激进，PO反而可以让他们意识完整的需求和要求，做出更现实的估算。估算不准去，PO也有责任。