Scrum Meeting

1.Sprint 计划会议

定出 Sprint 目标和既定产品 Backlog（做出估算）

故事点数（单位可用 人/天）

编辑一个用户故事：作为~~~,我想~~~,以便于~~~~~

2.Daily Scrum 每日例（立）会

目标

　　团队成员间工作进度的沟通和协调

会议准备

• 邀请与会者：团队所有成员、Scrum Master、产品负责人（可选）、相关人员（可选）
• 在 Sprint Backlog 上的所有任务都是可以增删修改，可重排序的
• 任务的状态可设为todo、doing、done（可以再加一个test表示需要验证）

会议进程（15 分钟内）

• 上次会议时的任务哪些已经完成：把任务从“正在处理”状态转为“已完成”状态
• 下一次会议之前，你计划完成什么任务？
  • 如果任务状态为“待处理”：转为“正在处理”状态
  • 如果任务不在 Sprint Backlog 上：添加这个任务
  • 如果任务不能在一天内完成：把这任务细分成多个任务
  • 如果任务可以在一天内完成：把任务状态设为“正在处理”
  • 如果任务状态已经是“正在处理”：询问是否存在阻碍任务完成得问题
• 有什么问题阻碍了你的开发：如果有阻碍你开发进度的问题，把该障碍加入到障碍 Backlog 中
• 如果展开了一个问题的讨论：提醒团队的成员们注意把精力集中在回答关键问题上
• 如果相关人员想发表些言论：礼貌地提醒他，该会议只允许让小组成员讨论

会议结果

• 得到最新的障碍 Backlog
• 得到最新的 Sprint Backlog
• 最新的工作进度图

其他

　　 可以指定一个主持人（或轮流）。他来召集并控制会议时间，会议中注意引导话题，在会议结束时可以做个简短的总结，说出重点就行，做好每日规划。

3.评审会议

在sprint周期最后，需要进行一次评审会议，让团队向干系人（经理和客户）展示已完成的功能。sprint审核的大部分实践用于团队成员展示功能、回答利益相关者对展示的疑问并记录所期望的更改。评审会议可以吸引相关利益者的关注，让其他人了解团队在做些什么，并得到重要反馈。做演示也会迫使开发团队真正完成一些工作。 

不要太正式，一般在2小时左右

其他

• 让演示关注业务层次，不要关注技术细节。注意力放在“我们做了什么”，而不是“我们怎么做的”
• 有的sprint可能会包含很多bug修复等功能，在评审会议中不要演示太多一大堆细碎的bug修复，除非这个很重要。

4.回顾会议（15~30min）

• 定期自我检查，发现什么好，什么不好
• 每个Sprint都要做
• 全体成员都要参加
• 准备一个回顾白板，分三列。第一列和第二列是回顾过去，第三列是展望将来。
  • Good：如果重做同一个sprint，哪些做法可以保持
  • Could have done better：如果重做同一个sprint，哪些做法需要改变
  • Improvements：有关将来如何改进的具体想法