1. 制定产品Backlog
产品Backlog是经过优先级排序的动态刷新的产品需求清单，用来制定发布计划和迭代计划。
另外，还可以记录 Track（类别）例如“后台系统”或“优化”, Requestor（需求提出者），Bug tracking ID（Bug跟踪ID），其他人也可以添加backlog。（以上backlog内容或在sprint会议上有更改。）
2. 召开sprint计划会议产生的成果
确定sprint目标（为什么要做）
团队成员名单（以及他们的投入程度，如果不是100%的话）
sprintbacklog（即sprint中包括的故事列表）
估计生产率由开发团队决定，（product owner可以调整优先级）
确定好sprint演示日期（三周可以参考）
确定好时间地点，供举行每日scrum会议。
会议启动以后，产品负责人一般会先概括一下希望在这个sprint中达成的目标，还有他认为最重要的故事。接下来，产品负责人，开发团队开始讨论关于重要性，估算时间，范围，根据讨论结果，有可能会修改product backlog。
外部质量是有产品负责人决定，到底以最终什么效果展现给用户。内部质量不能妥协，可以降低其中backlog的优先级，或砍掉一些模块。
计划会议示例：
（可以调整）每个story需要多少人天
3. 利用索引卡记录productbacklog
分两队拆分backlog，拆成任务，统一意见后，记录到即时贴上，贴在相应的backlog下面。
利用计划纸牌来估算，每个人发13张卡片，估算这个故事全部任务。
0 = “这个故事已经完成了”或者“这个故事根本没啥东西，几分钟就能搞定”。
? = “我一点概念都没有。没想法。”
咖啡杯 = “我太累了，先歇会吧。”
其他数字只是大概估计，如果无法估算，把任务拆分。如果两个人估算差异很大，讨论后，有必要是拆分任务。
4. 明确故事内容，产品经理对范围一定要明确，到底做成什么样
故事的大小在2至8个人-天之间。一个普通团队的生产率大约是40-60，所以大概每个sprint可以完成10个故事。
5. 技术故事也要解决
如重构dao，编写概要设计，安装持续构建服务器，升级jira等，如果影响进度，把它作为故事放到sprint中，或掺杂在其他故事中。对于优先级较高的bug，带到sprint会议上，与story同等对待。
www.bht.com.cn
本文由华铁海兴原创文章，未经许可不得转载。
