Sprint Planning
会议名称
冲刺计划会议 (Sprint Planning Meeting)
会议举行时间
冲刺周期开始当天的早上（可以取代当日站会）
会议时间
每周工作量伴随1小时的冲刺计划会议，如果团队每两周冲刺一次，冲刺计划会议就应该是2小时长
会议参与人
Product Owner，Scrum Master，全体项目成员，请Master在合适时间主动发出会议邀请
目标
让开发团队了解开发任务，分析与预估用户故事难易度，并决定接下来冲刺要完成的工作项
- Scrum Master分享桌面，将上次冲刺回顾会议制定出来的改善项目与整个团队过一遍，确保团队在这一次冲刺当中改进了上次列出来的改善项
- Product Owner分享桌面，从Backlog中第一个任务开始跟团队简易介绍任务内容，介绍完毕后留60秒的时间让团队开放讨论为了实现这个用户故事需要设立多少子任务，然后给10秒钟的时间让团队成员给出故事点预估
- 在两个小时内尽可能多的预估任务
- Scrum Master分享桌面，设置新的Sprint，根据团队的平均速度(Velocity)，将等同120%团队速度的任务从最高优先级，按照一定比例，在用户故事都已完善并且有验收条件的前提之下，开始拖拉到冲刺Backlog当中，并用一句话简单描述冲刺目标，确保团队成员都认同目标后，开始冲刺。
120%原则
例如团队的平均速度是60点，我们会在冲刺中安排72点的工作量，这是为了避免团队提早做完冲刺中的任务而发生无事可做的窘境。
任务分配Backlog中的任务一般可以分成三种类别，
- 技术债（Technical Debt）：为了加速开发流程，工程师往往会在应采取最佳方案时做了妥协，采用了短期内可以加速开发流程的作法，但长远来看会成为迟早要填的坑，这种东西就叫技术债。常见的技术债诸如"缺乏文档"，"缺乏测试方案"，"没有按照标准流程做事情"，"因为项目时程紧张所以很多没做但应该做的事情"，"需求本身没有考虑技术实现问题而挖的坑"等等，这都是团队为了填坑自己给自己建的任务，因为一开始方便，后来迟早要还的观念，才称之为"债"。
- 故障（Bugs）：由终端用户或是QA工程师在测试过程当中发现的Bug，会以故障的形式记录在Backlog中，等待开发团队安排时间完成的任务。
- 新功能（New Features）：由Product Owner直接安插进Product Backlog的用户故事，一般都是新功能需求，这些新功能需求直接对客户输出了价值，是三种任务当中客户最想要的。
一般建议在每一次的冲刺当中，我们应该安排7成任务实现新功能，3成任务修复Bug与填坑。
