上面的会议通常持续10-15分钟，由团队主管(ScrumMaster)主持，一般问就下面3个问题展开。
所有测试人员都聚拢在测试状态板前，讨论如何最好地利用当天的时间。隶属于具体功能开发团队的测试人员刚刚跟各自所属的团队开完立会，所以他们可以分享各个团队的最新进展。
与此同时，需求分析团队则在开他们自己的同步立会。刚刚跟功能开发团队开完立会的分析人员也来参加会议，他们有最新的信息可以向整个需求分析团队汇报。
参加项目同步立会的人员被称为交叉型团队。我们在这个项目里，就是每个专业派一个代表，每个功能开发团队派一个代表，再加上其他几个人，比如项目经理、配置经理和我自己。
我们在项目同步立会上审视整个项目的状况，主要关注从需求分析到投入生产的各个工序是否正常运转：
这个体系看上去很像瀑布开发模式。其实不然，在看板系统中，这些不同的阶段都是并行的。
不能把所有的任务板塞满。
用警车标出需要特别快速处理的紧急事项。
用粉红色便利贴来标示障碍。
随着项目成员增加，每个团队成员都有自己的任务看板，显示团队自己的工作进度。但是却不清楚项目的整体状况。
如果人人都清楚总体目标是什么，就会更关注总体目标。
最重要的两个定义是“可供开发”和“可供系统测试”，因为这两处是我们以前出现问题最多的地方。一个功能进入可供开发状态，就必须具备以下特点:
可供系统测试：
流程改进提案示例
只有4栏work in process。
流程度量非常有用，可以找出哪里需要改进，看出我们所作的变更是否带来了积极的效果。对于从宏观上规划版本发布大纲也很有用。我们追踪以下两个流程度量：
可将其用作现实检查工具，检验版本发布计划是否切实可行。
根据这一数据来预测截至某个时间点大致可完成的功能数。
主干无垃圾
团队分支
系统测试分支
原文地址：http://blog.csdn.net/limingjian/article/details/40684655
