本文主要是为了检测你对SCRUM Sprint 计划会议的了解和使用程度,
通过本文你可以检测一下
1、你们的SCRUM Sprint 计划会议的过程和步骤
2、会议的输出结果
Sprint 计划会议非常关键，应该算是 Scrum中最重要的活动（这当然是我的主观意见）。要是它执行的不好，整个 sprint 甚至都会被毁掉。
举办 Sprint计划会议，是为了让团队获得足够的信息，能够在几个星期内不受干扰地工作，也是为了让产品负责人能对此有充分的信心
一、会议目的
1、定出 Sprint 目标和既定产品 Backlog
2、该会议的工作以分析为主，目标是要详细理解最终用户到底要什么。产品开发团队可以从该会议中详细了解最终用户的真实需要。在会议的结束，团队将会决定他们能够交付哪些东西。
基本要求：
只有团队成员才能决定团队在当前 Sprint 中能够领取多少个 Backlog 条目的工作。
二、会议时间
在Sprint 中，每周该会议占用时间为 60分钟。在早上召开该会议，
这样还有可能在同一天召开 Sprint规划会议的第二部分。
三、会议准备
1. 邀请与会者：
产品负责人
Scrum Master
团队所有成员
2. 已按优先级排列产品 Backlog 中各项问题
3. 已评估 Backlog 中的各项问题
4. 把产品 Backlog 公开给会议中的每个人，保证其可被获取
5. 预期团队中有哪些人已明确会缺席（如度假）
6. 保证房间环境适合小组讨论
7. 每个人都可以获取上次 Sprint 评审会议和 Sprint 回顾会议的结果
8. Sprint 时间表已经安排
9. Sprint 计划会议 1 的时间安排
10. Sprint 计划会议 2 的时间安排
11. Sprint 的第一天已确定
12. Sprint 的最后一天已确定
13. Scrum 每日例会的时间安排
14. Sprint 评审会议的时间安排
15. Sprint 回顾会议的时间安排
四、会议进程
1. 把 Sprint 时间表公开给所有人
2. 把 Sprint 评审会议的结果公开给所有人
3. 把 Sprint 回顾会议的结果公开给所有人
4. 产品负责人向团队产品阐述产品远景
5. 产品负责人和团队一起确定 Sprint 目标
6. 从第一个 Product Backlog条目（故事）开始。
7. 讨论该 Product Backlog条目，以深入理解。
8. 分析、明确用户验收测试。
9. 找到非功能性需求（性能、稳定性……）。
10. 找到验收条件。
11. 弄清楚需要“完成”到何种水平。
12. 获得 Backlog 条目各个方面的清晰了解。
13. 绘制出所需交付物的相关图表，包括流程图、UML 图、手绘草图、屏幕 UI设计等。
14. 回到步骤 1，选取下一个Backlog条目
流程检查：
询问团队能否快速回答下列问题，只需简要回答即可：“我们能在这个 Sprint中完成第一个 Backlog 条目吗？”如果能得到肯定回答，那么继续询问下一个Backlog条目，一直到已经分析完的最后一个Backlog 条目。
接下来，休息一下。
在休息之后：
对下一个 Backlog条目展开上述流程。
结束流程：
1. 在Sprint 规划会议第一部分结束前留出20分钟。
2. 再次提问——这次要更加严肃、正式：“你们能否完成第一个 Backlog 条目，……第二个，……？”
3. 如果团队认为他们不能再接受更多Backlog条目，那就停下来。
4. 现在是非常重要的一步：送走Product Owner。她必须离开！所有的人，除了团队和 Scrum Master 之外的所有人，都得离开。客户、最终用户，所有其他人都得离开！
5. 当其他人都离开后，再询问团队：“说真的——你们相信自己可以完成这个列表？”
6. 希望团队现在能短暂讨论一下，看看他们到底认为自己能完成多少工作。
7. 将结果与 Product Owner和最终用户沟通。不许再讨论了！
五、会议结果
1. 为 Sprint 计划会议2的进行准备好既定产品 Backlog
2. 选择好的 Product Backlog条目。
3. 各个Backlog条目的需求。
4. 各个Backlog条目的用户验收测试