Scrum是一个“检查并适应”的框架，在三个角色（产品负责人/Scrum Master/团队）、三种仪式（Sprint计划/Sprint回顾/每日例会）和三种制品（产品Backlog/Sprint Backlog/燃尽图）的基础上，你可以根据公司或者项目的情况，因地制宜引入任何有利于缩短开发周期、提高产品质量的实践。
Product Owner(Product master)：
产品负责人（PM）收集整理产品需求，形成产品Backlog；
产品Backlog按照统一格式定义，比较重要属性有：名称、重要性、估算时间、简单描述、如何演示等，详细的需求细节可以在其他需求文档中定义；
产品负责人可以通过任何渠道、方式获取和确认需求；
怎么做Scrum
产品负责人、Scrum Master和团队成员（包括QA）召开Sprint会议，Scrum Master主持会议;
Sprint会议上详细沟通产品负责人选定的重要性高的产品Backlog细节，确保团队对需求的理解无误;
团队就对需求的理解将Backlog拆分成任务，并给出每个Backlog的估算时间; ;
产品负责人和团队根据Sprint内可用的人天和Backlog的时间估算，选定需要排入本次Sprint的Backlog
Scrum Master和团队分派任务，制定Sprint计划;
一个Sprint的周期是两周；一次Sprint会议时间大约一个下午;
整理一面任务墙，将Sprint内的Backlog和任务按照未开始、进行中、已完成等状态进行归类；同时展示Sprint的燃尽图;
Scrum Master每日早上固定时间组织团队的每日例会，确认每个成员前一天完成的工作、当天要进行的工作、工作中碰到的issue，并更新任务墙;
任何需求变更都进行实时评估，超过规划人天的Backlog视情况进行拆分或者推迟其他重要性低的Backlog;
任何完成的Backlog都需要演示给产品负责人和QA后才能提交测试;
Sprint后的工作：
Scrum Master召集、组织Sprint回顾会议
回顾会议以头脑风暴的方式Review Sprint过程和结果，发现和列举存在的问题
与会人员投票决定需要在下个Sprint中解决的1-3个问题， 探讨解决方案，确定实践方式
归纳总结：
Scrum 价值观：
个体与交互 重于 过程和工具
可用的软件 重于 完备的文档
客户协作 重于 合同谈判
响应变化 重于 遵循计划
scrum 十二条准则：
我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
项目过程中，业务人员与开发人员必须在一起工作。
要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
可用的软件是衡量进度的主要指标。
敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
对技术的精益求精以及对设计的不断完善将提升敏捷性。
要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
最佳的架构、需求和设计出自于自组织的团队。
团队要定期反省如何能够做到更有效，并相应地调整团队的行为。