四场仪式
Scrum中共有四场仪式，分别是计划会,站会,评审会,回顾会。
计划会
计划会的目标是创建冲刺计划（Sprint Backlog），又可以细分为：
从
Product Backlog中选择要处理的事务选定的用户故事则为Sprint目标
将用户故事拆分为Tasks
计划会也是一个时间盒，通常一个月的Sprint计划会时间不宜超过8个小时（即一个工作日）。
在实际实施中，通常会按照以下两个步骤操作：
按照Product Backlog中排列的优先级从高到低对条目进行估算，不用全部估算完，估算的条目数够用即可
按照团队以往的交付速率，选取按照平均速率团队在一个Sprint中能够完成的条目加入到Sprint Backlog
估算
在我们以往的实施经历中，估算一直是一个难题，由于对故事细节的理解不清晰，估算通常与实际相差很大。但就个人经验来说，估算的目的并不是为了精确估算，而是通过这种形式能够促使开发团队能够尽量去理解故事细节，另外通过开发团队提问，产品负责人澄清的方式，也能够帮助产品负责人下次写出更清晰的用户故事。
估算有以下几个要点：
估算不是承诺，不存在事后追责
相对估算，即可以选择一个大小适中的用户故事作为1个故事点的参照，其他用户故事可参考进行相对估算。
也可使用理想时长作为估算单位，所谓理想时长是指全身心投入的时长（我们经常举的例子是把所有伸懒腰倒茶喝水上厕所的时间全部不计算进去）
对于用户故事特别多的情况，有一种叫做快速排序的方法，具体操作是：
将所有用户故事按照估算大小排好，大小差不多的可以放在同一列。
按照斐波那契数列直接给所有用户故事赋上故事点数。（1/2,1,2,3,5,8,13…）
个人理解选取斐波那契数列而不选用连续自然数的原因是因为强调是估算，故事越大的时候估算必然是越不准的，所以无需纠结1-2点的误差。
估算故事点的主要意义除了促使开发团队提前理解用户故事和帮助产品负责人写出更好的用户故事，还有另外一个比较重要的意义是估算团队交付速率，团队交付速率可用于：
预测项目完成日期
计划下个Sprint的交付能力
理想的情况团队交付速率应该前期呈上升趋势，到一定时间开始趋于平稳。
站会
站会也是一个时间盒，通常每日站会时间不超过15分钟，站会的主要目的是开发者之间的信息同步，信息同步的主要价值以个人经历来说，在于识别目前存在的瓶颈，最典型的是一个简单问题可能导致某一个项目成员的进度停滞，而通过信息同步，其他项目成员帮助其快速解决遇到的瓶颈。
团队成员应该将团队目标作为主要目标，可能自己钻研能够帮助到自己的成长，但是在团队目标面前，应该优先考虑团队目标的达成。
站会上通常每个人会回答以下3个问题：
上个Daily Scrum到现在，我做了什么
到下个Daily Scrum之前我准备做什么
我遇到了什么问题
评审会
评审会也是一个时间盒，通常一个月的Sprint评审会时间不超过4个小时。评审会的主要内容是Scrum团队给客户演示增量并接收客户反馈，从而更好为之后的迭代改进提供输入。
评审会体现的是敏捷中的适应性。
回顾会
回顾会也是一个时间盒，通常一个月的Sprint回顾会时间不超过3个小时。回顾会的主要内容是Scrum团队回顾当前迭代过程，分析存在的异常，总结改进措施作为下一个迭代的待办项。
在以往实施经历中，通常会把回顾会的气氛搞得相对轻松些，回顾会不是追责会，需要让大家畅所欲言。