在 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 團隊的設置應以相互配合、相互補充為主要考慮因素，保證團隊自我管理、獨立解決問題的能力，這在一定程度上也可以解決前面提到的團隊依賴的問題。
