先来看一个时间表：
Sprint 计划会议：
• 13:00 – 17:00 （每小时休息10分钟）
• 13:00 – 13:30。产品负责人对sprint目标进行总体介绍，概括产品backlog。定下演示的时间地点。
• 13:30 – 15:00。团队估算时间，在必要的情况下拆分backlog条目。产品负责人在必要时修改重要性评分。理清每个条目的含义。所有重要性高的backlog条目都要填写“如何演示”。
• 15:00 – 16:00。团队选择要放入sprint中的故事。计算生产率，用作核查工作安排的基础。
• 16:00 – 17:00。为每日scrum会议（以下简称每日例会）安排固定的时间地点（如果和上次不同的话）。把故事进一步拆分成任务。
仅供参考。
在sprint计划会议之前，要确保产品backlog的井然有序。
注意：产品负责人之外的人也可以向产品backlog中添加故事，但是他们不能说这个故事有多重要，这是产品负责人独有的权利。他们也不能添加时间估算，这是开发团队独有的权利。
Sprint计划会议非常关键，应该算是Scrum中最重要的活动。要是它执行的不好，整个sprint甚至都会被毁掉。
举办Sprint计划会议，是为了让团队获得足够的信息，能够在几个星期内不受干扰地工作，也是为了让产品负责人能对此有充分的信心。
Sprint计划会议会产生一些实实在在的成果：
sprint目标。
团队成员名单（以及他们的投入程度，如果不是100%的话）。
sprint backlog（即sprint中包括的故事列表）。
确定好sprint演示日期。
确定好时间地点，供举行每日scrum会议。
1.在进行sprint计划会议前就准备好backlog，可以由需求人员与技术经理一起讨论决定；
2.准备好的backlog中必须包括如下内容：
•ID——统一标识符，就是个自增长的数字而已。以防重命名故事以后找不到它们。
•Name（名称）——简短的、描述性的故事名。比如“查看你自己的交易明细”。它必须要含义明确，这样开发人员和产品负责人才能大致明白我们说的是什么东西，跟其他故事区分开。它一般由2到10个字组成。
•Importance（重要性）——产品负责人评出一个数值，指示这个故事有多重要。例如10或150。分数越高越重要。
•Initial estimate（初始估算）——团队的初步估算，表示与其他故事相比，完成该故事所需的工作量。最小的单位是故事点（story point），一般大致相当于一个“理想的人天（man-day）”。
•How to demo（如何做演示）——它大略描述了这个故事应该如何在sprint 演示上进行示范，本质就是一个简单的测试规范。“先这样做，然后那样做，就应该得到……的结果”。
•Notes（注解）——相关信息、解释说明和对其它资料的引用等等。一般都非常简短。
3.backlog可以预先维护在jira中， Initial estimate预先不必填写，在进行计划会议时需要由开发团队决定。
4.计划会议重点对 How to demo和Notes进行讨论，讨论结果必须确定，并要求团队中每个人员都清楚，开发人员以此为依据进行设计开发，测试人员以此为依据进行用例编写。
示例：
