全员会议。
不超过两个小时为宜。
这个主要是组成团队，培养团队士气，了解项目背景等。
评估会议
不应超过4个小时。
根据产品负责人产出的产品backlog，由产品负责人推动，对产品backlog中的用例条目进行工作量估算，最终产出一个优先级明确的，已有初步估算结果的比较稳定的产品backlog.
sprint计划会议
一般时间不超过4个小时。如果超时过多，则应拆分为两个会议。
根据评估会议的产品backlog，产品负责人和团队master以及团队一起，进行产品backlog到sprint的划分，选取合适的用例条目生成每一个sprint合适的task（story）,然后大家一起确定sprint的目标，这里当然要精确到how to demo的级别了。sprint计划会议室scrum中最重要的会议，产品负责人团队成员团队master必须全部参加，这里完成的是业务产品backlog到实现的sprint backlog的转化。相当于业务需求到开发人员认识的功能需求的转化。
sprint计划会议2
不超过4个小时
如果有必要，这个会议也要开，比如上一个计划会议有些目标没能达成，或者是sprint中的任务粒度太粗，不适宜短期完成，则在这个会议上进行拆分细化，以保证数目不多的story point都能有可度量的产出。
每日晨会。
每日晨会应该控制在15分钟左右，并且应该主要以这样4个问题为主导。
1. 完成了什么story
2. 将要做什么
3. 当前障碍时什么。
以上三个问题是针对团队成员中的pigs(这里指对story的done直接负责的那些图阿奴地成员)
4. how are we doing?
这个问题是针对全体团队成员提问，以整体把握sprint的进度，比如测试环境准备的怎么样了？各种协调怎么样了？让团队成员能够了解sprint整体进度，并能及时调整应对变化，以保证尽可能的按照deadline提供出可demo的sprint.
sprint成果展示
这里的展示时间尽量不要超过90分钟。
每个sprint结束时，都应该有这个展示，可以邀请客户，相关技术人员，相关的其他团队等参加，以让产品为大家所知，提高团队的成就感。展示的一定要是done的sprint中的task,如果其中有未完成的，则不应该展示。展示主要以功能展示和性能测评这些比较笼统的展示为主，不要太局限于细节。展示出特色即可。
sprint 回顾
回顾会议不超过2个小时为宜。
主要以回顾整个过程，整理出好的实施，提出缺陷，并给出解决方案。可以结合SWOT分析法来总结出团队的特点，并以此来改进团队，让团队水平更高。
另外，我觉得sprint之间必须有一个间歇期，最好取在周五。这个间歇期可以让团队成员调整状态，消化吸收整个sprint中的成果，学习新技术等等，让团队成员劳逸结合，又能得到成长。对团队士气和团队成长都是很有益处的。