6、sprint评审会议
sprint评审会议是在sprint完成时举行，要向客户演示自己完成的软件产品 。
7、sprint总结会议
最后是sprint总结会议，以轮流发言方式进行，每个人都要发言，总结上一次sprint中遇到的问题、改进和大家分享讨论。
三、敏捷实施过程中的关键点
1、三个角色
1.1产品负责人
1.2团队负责人
1.3团队成员
在团队确定采取实施敏捷前，由团队成员自己讨论定制出一套所有人都认同的规则（针对日常活动）；
制定出来的协议需要每个人都能遵守和互相监督；工作协议要满足下面几条：
制定的协议要是可实行的；
有具体的判断标准；
每个人都认同的。
在此基础上再实施敏捷开发。
2、三个工件
2.1产品功能列表:Product Backlog ( PBls )
产品功能列表包含用户故事内容，优先级及工作量估算的列表。
下图是一个产品功能列表示例：
2.1.1用户故事
用户故事是首创于极限编程（XP）的管理用户需求的基本方法，目前已广为各个敏捷实践方法和技术所借鉴和使用。Scrum将用户故事作为最基本的需求管理工具，组成了称之为产品功能列表（Product Backlog）的用户需求列表。
用户故事从用户的角度描述用户渴望得到的功能和实现的价值。
用户故事描述对用户，系统或软件购买者有价值的功能。由以下两方面构成：
2.1.1.1故事描述
一个好的用户故事描述包括三个基本要素：
◉ 角色：谁要使用这个功能。
◉ 活动：需要完成什么样的功能。
◉ 商业价值：为什么需要这个功能以及这个功能带来什么样的价值。
用户故事描述公式为：作为XXX【角色】，我想XXX【活动】，以至于XXX【商业价值】。
2.1.1.2验收测试
验收测试用来验证实现的用户故事是否符合客户团队的期望，有点类似于之前的需求描述。需要尽可能把所有满足此用户故事的情况考虑在内。
用户故事拆分的要尽可能的小，大小是一天的开发工作量。
注意：在一张纸上，正面写故事描述，背面写验收测试。
下图是用户故事的一个示例：
2.2冲刺列表:Sprint Backlog ( SBls )
下图是用户故事地图和冲刺列表示例：
用户故事地图就是从左至右按时间顺序罗列用户行为（也就是流程的每一步），在每个用户行为下从上至下罗列相应的细节，包括所需要的开发点，构成一个二维的“地图”。基于这个地图，还可以对每个开发点的业务价值进行审视，找出最小可用产品（MVP）并制定发布计划。
将用户故事进行拆分，拆分成团队成员可以认领的任务，并定义好每个冲刺需要完成的功能内容，建立冲刺列表，形成用户故事地图。
2.3燃尽图:Burn-Down Chart
燃尽图是在Scrum开发过程中一个非常重要能够反映出当前冲刺执行情况的图表。典型的燃尽图横坐标表示冲刺的具体日期，纵坐标表示剩余工作量（或故事点），虚线表示理想趋势，实线表示实际工作量（或故事点）变化情况。
如下是一个项目迭代周期内的一张燃尽图示例：
燃尽图作为敏捷可视化管理的工具，发挥着重要的作用。作为敏捷教练应当能够从每一张图表、每一条折线，分析出项目背后的问题，防范于未然。燃尽图的数据来源于日常工作，出自于团队本身。所以数据的准确性，直接决定了燃尽图的价值。
要想团队的燃尽图是有价值的，必须做到下面几点：
◉ 数据要真实，统计全面。这样才能反映出task的执行情况。
◉ 对于工作量的预估要尽量准确，这就对团队的技术水平有一定的要求。
◉ 粒度的分解要尽量落实到每一天。太大的粒度无法跟踪，而且不利于工作的估计。
