在 Sprint 计划会议中，PO 根据团队的能力及以往的表现，与团队成员一起从产品 Backlog 中挑选有价值（或风险大）的条目，经过初步估算，确定出下一个 Sprint 的工作目标（即明确做什么），进而由开发团队对挑选出的条目进行分析、讨论和进一步估算形成任务列表（即明确怎么做）。

每日站会中，每个团队成员通过回答“从上次会议到现在都完成了哪些工作”，“下次每日会议之前准备完成什么工作”，“工作中遇到了哪些障碍”，来加强团队成员的交流沟通，提高每个成员对项目的认知程度，检验项目实施情况，并通过快速决策，排除开发过程中遇到的障碍，保证项目的顺利进行。

Sprint 评审会议在 Sprint 的末尾举行，通过成果展示，围绕团队在 Sprint 内完成的可交付物来确定目标完成情况，并为后续 Sprint 计划提供参考。

Sprint 回顾会议通过回顾已经完成的 Sprint，总结经验教训，确定做出什么样的改善可以使接下来的 Sprint 更加高效、更加令人满意，从而实现对开发过程的持续改进。

跨区域Scrum团队面临的挑战

Scrum 通过加强沟通快速解决项目实施过程中遇到的问题，同时通过对各个 Sprint 的回顾和评审，来改进开发过程，并为后续 Sprint 提供参考，有效地保证了 Scrum 短周期迭代的顺利进行。

但是，对于跨区域 Scrum 团队，尤其是分布在不同时区的 Scrum 团队（如笔者参与开发的项目，涉及分布在亚洲和北美洲的 3 个时区的数个开发团队）而言，则面临着许多新的问题，主要表现在：

会议成本增加，有时很难进行面对面沟通，每日站会往往无法全员参加。

项目启动的 Sprint 计划会议往往需要相对较长时间（数小时到），处在其他区域的 PO 往往在时间上无法保证。
由于无法进行实时沟通，一旦项目进行过程中出现之前无法预料的问题，尤其是是功能模块或接口的相互依赖问题，所造成的时间延迟往往比本地项目出现类似问题所造成的延迟要多得多，从而直接影响受影响团队 Sprint 目标的达成。

解决方案

在笔者参与的跨区域 Scrum 开发团队中，为了解决以上问题，项目团队以 Scrum 指导原则为基础，对项目团队的工作作出调整，并提出了几个有针对性的解决方案。

团队代表制，解决跨区域 Scrum 会议问题

组成 Scrum of Scrums 团队，采用 Weekly Scrum Meeting（每周电话或电视会议）同步各 Scrum 团队项目进展情况，并重点解决团队依赖问题；同时成立独立的架构咨询团队，负责协助在会后讨论并解决（主要以邮件的形式）在该会议上无法快速解决的团队依赖问题。

由于涉及多个时区的原因，每周电话或电视会议无法保证在工作时间举行，因此，由各团队成员轮流参加，各 Scrum 团队每周派一名代表提前收集意见，为会议作准备，并代表本 Scrum 团队在会议上发言。会议的内容除汇报各 Scrum 团队的进度外，还包括：是否对产品的公共模块作出了重大修改，是否有大量的代码提交，是否在某一方面依赖于其他 Scrum 团队的工作，是否需要其他 Scrum 团队提供技术支援（某一技术问题提供专家意见，并非直接参与项目的实施），并预告重大的架构调整及受影响的模块，预告即将引入的新技术或功能及可能带来的影响等等。

此外，架构咨询团队还负责为各开发团队提供架构设计方面的指导，大程度上减少团队依赖问题的产生。

对于 Scrum 团队的设置，虽然本地团队可以更好地保证沟通的质量和效率，但在大多数的情况下，并不要求同一 Scrum 团队的所有成员处在同一地点或同一时区。现代通信手段丰富多样，只要保证沟通顺畅，Scrum 团队的设置应以相互配合、相互补充为主要考虑因素，保证团队自我管理、独立解决问题的能力，这在一定程度上也可以解决前面提到的团队依赖的问题。