1.用户需求分析转化为产品BACKLOG
这个部分的内容由PM具体负责，主要的工作内容如下：
用户调研、需求分析，确定产品迭代功能，出具产品BACKLOG。决定产品的发布日期与发布内容，给迭代计划预设目标。根据RIO（商业价值/工作量）排序优先级，考虑必要风险。
优先级排序：排序的目的，是弄清楚哪些需求最重要因此可能在最近的一两次迭代中进行开发。参与排序的条目一般足够接近半年的开发工作量，但多数只有一个简短的名称，只有最高优先级的需求才会被真正细化，也就是近一两次迭代要开发的需求列表。在每个Sprint结束或者临时需求变更时，都需要更新优先级的排列顺序。
关键物：产品BACKLOG
如图：
2. Sprint计划会议生成Sprint BACKLOG
这个部分的内容主要由开发经理负责，主要工作内容如下：
将产品BACKLOG拆分为在本次Sprint中可细化的Sprint BACKLOG。Sprint BACKLOG中的开发任务以小时估算，预计1-16小时的工作量化。根据开发优先级管理Sprint BACKLOG，随时更新Sprint BACKLOG状态。每个团队成员都可以自主挑选任务，修改Sprint BACKLOG。
优先级排序：要完成这个选择其实不太容易，如果只是盯着产品BACKLOG“重要程度”这个排序依据，极有可能从很多功能模块中各自挑出最重要的需求，而这些需求凑在一起，只能形成一个四不像的版本。因此常常可以挑选最重要的功能模块中的多个条目，形成整体完整的一个“故事群”，这样无论开发、测试和演示环节，都有一个相对内聚的目标。为了防止大家中途跑偏，常常给每个冲刺要都起一个简短的名称，比如：“本次迭代将发布一个具有电子节目单的版本。”
关键物：Sprint BACKLOG
如图：
3.迭代开发周期，每日例会，交付迭代版本
这部分内容主要由开发团队共同推进，主要工作内容如下：
依照Sprint BACKLOG，开始开发工作，更新工作任务面板。参加每日例会，围绕昨日进度、今日安排、所遇困难三个方面快速的梳理一遍任务面板上的工作内容，所遇困难在会后点对点进行讨论解决。保证整体开发进度不大幅度的偏离预设的Sprint燃尽图。高度的自我组织管理，保持良好的跨职能团队沟通，确保实现Sprint目标。
优先级排序：一般在迭代计划会上使用MoSCoW方法进行这种排序，将要Sprint Backlog中的条目分为四级（其实只有前3级）：
Must：必须做的
Shoud：应该做的
Could：可以做的
Would not：不要做的
要按照这些顺序来做，保证Product Owner所需要的Must、Should完成，并力争Could能完成；在发生重要变更的时候，牺牲Could乃至Should保证变更。开发过程中避免在M、S完成前就有人动C。
关键物：燃尽图
如图：
4.验收发布版本，评审回顾会议，周期数据报表
这部分内容主要由Sprint团队成员共同参与，主要工作内容如下：
产品开发团队通过操作演示的方式展示Sprint中完成的功能与架构。PM根据产品BACKLOG，验收开发交付的迭代版本，发布产品迭代版本。收集Sprint问题反馈，寻找根本原因，讨论解决方法，改善Sprint过程。
参考文章：
http://cloud.51cto.com/art/201711/559483.htm
