迭代计划会（Sprint Planning Meeting）
1、迭代计划会在每个迭代的第一天召开，目的是选择和估算本次迭代的工作项。
2、产品负责人逐条讲解最重要的产品功能。
3、开发团队共同估算故事所需的工作量，知道本迭代工作量达到饱和。
4、产品负责人参与讨论并回答与需求相关的问题，但不干扰估算结果。
迭代计划会I（产品Backlog）
会议准备：
1、邀请与会者（产品负责人、ScrumMaster、团队所有成员）
2、已按优先级排列产品Backlog中的各项问题
3、已评估产品Backlog中的各项问题
4、把产品Backlog公开给会议中的每个人，保证其可被获取
5、每个人都可以获取上次Sprint评审会议和Sprint回顾会议的结果
6、Sprint时间表已经安排：
a. Sprint计划会议1的时间安排
b. Sprint计划会议2的时间安排
c. Sprint的第一天已经确定
d. Sprint的最后一天已经确定
e. Sprint每日例会的时间安排
f. Sprint评审会议的时间安排
g. Sprint回顾会议的时间安排
会议进程：
1、把Sprint时间表公开给所有人
2、把Sprint评审会议的结果公开给所有人
3、把Sprint回顾会议的结果公开给所有人
4、产品负责人向团队成员阐述产品远景
5、产品负责人和团队一起确定Sprint目标
6、如果Backlog里有问题遗漏：产品负责人有权往Backlog里添加问题
会议结果：
为Sprint计划会议II的进行准备好既定产品Backlog
迭代计划会II（SprintBacklog）
会议准备：
1、邀请与会者（产品负责人、ScrumMaster、团队所有成员）
2、既定产品Backlog
3、记录任务时需要的卡片或贴纸
会议进程：
1、团队成员从Backlog的各项问题中分出相应的任务。
2、确保考虑到工作中的所有细节
a. 编码
b. 测试
c. 代码评审
d. 会议
e. 学习新技术
f. 编写文档
3、如果任务需时超过一天：尝试把该任务分割成几个小任务。
4、如果团队认为SprintBacklog中项过多：和产品负责人一起删减Backlog中的问题。
5、如果团队认为SprintBacklog中项过少：和产品负责人一起从产品Backlog中选出最重要问题，加入SprintBacklog中。
6、团队确认Sprint目标。
会议结果：
1、Sprint目标和SprintBacklog对于公司内的所有人都是公开的
2、所有团队成员都可以获取SprintBacklog中的任务
产品负责人准备什么？讲解什么？
1、会前准备：条目化的需求（用户故事），优先级排序，最近1-2个迭代最希望看到的功能。
2、会上讲解：较难以文字表述的内容。讲解过程中团队可以随时发问，产品负责人要予以解答。若产品负责人感觉答案没有想清楚，可以推迟故事的开发，或将故事分解为“已想清楚的”和“未想清楚的”，后者推迟到下一个迭代或更晚。
3、两者的关系：准备活动类似于电影剧本编写，它导致了这是不是一个好故事的基本问题；会上讲解类似于导演说戏，它导致了这个故事我们能不能演好的问题。
4、一般一个团队只有70%的工作可以进行正式工作，因此每个月安排15人天左右即为饱和，新团队则可能低至10人天。
团队怎样估算？
1、共同估算：在估算前不应该指定谁将开发这个故事，而是以接收故事的小组为单位集体估算，每个人提出自己的看法，大家综合。这样才能以集体智慧完成任务。
2、在估算过程，产品负责人不能离开，因为很多估算差异问题来自于“做什么，做到什么地步”，产品负责人需要予以解答，而不是让团队按自己的理解去做。
3、共同估算的目的不是一个数字上的统一，而是用集体智慧和知识对“做什么，怎么做”达成共识。
4、共同估算是共同跟进的基础，若不能共同估算，则后面的“每日站会”几乎不可能正常进行，因为大家只关心自己曾经一起分析，思考，提问，设计乃至于争论过的任务进展的怎样了，是不是和自己想象的一样。
5、共同估算的最佳方法是“扑克牌估算”。估算扑克是几个潜在的任务承担者（如某个功能小组）共同估算的方法，他们一起听产品负责人讲解，一起估算，以达到利用集体智慧解决问题的目的。
a. 每人各自估算后独立出暗牌，听口令一起开牌。
b. 数值最大者与最小者PK，其他人旁听也可参与。
c. 讨论结束后重新出牌与开牌。
d. 重复上述过程，知道结果比较接近。
其它会议：
在Sprint开始前，需确定各常规Scrum会议中的时间安排。
一般两周的Sprint，建议其常规的Scrum会议时间安排如下：