迭代計划會（Sprint Planning Meeting）
1、迭代計划會在每個迭代的第一天召開，目的是選擇和估算本次迭代的工作項。
2、產品負責人逐條講解最重要的產品功能。
3、開發團隊共同估算故事所需的工作量，知道本迭代工作量達到飽和。
4、產品負責人參與討論並回答與需求相關的問題，但不干擾估算結果。
迭代計划會I（產品Backlog）
會議准備：
1、邀請與會者（產品負責人、ScrumMaster、團隊所有成員）
2、已按優先級排列產品Backlog中的各項問題
3、已評估產品Backlog中的各項問題
4、把產品Backlog公開給會議中的每個人，保證其可被獲取
5、每個人都可以獲取上次Sprint評審會議和Sprint回顧會議的結果
6、Sprint時間表已經安排：
a. Sprint計划會議1的時間安排
b. Sprint計划會議2的時間安排
c. Sprint的第一天已經確定
d. Sprint的最后一天已經確定
e. Sprint每日例會的時間安排
f. Sprint評審會議的時間安排
g. Sprint回顧會議的時間安排
會議進程：
1、把Sprint時間表公開給所有人
2、把Sprint評審會議的結果公開給所有人
3、把Sprint回顧會議的結果公開給所有人
4、產品負責人向團隊成員闡述產品遠景
5、產品負責人和團隊一起確定Sprint目標
6、如果Backlog里有問題遺漏：產品負責人有權往Backlog里添加問題
會議結果：
為Sprint計划會議II的進行准備好既定產品Backlog
迭代計划會II（SprintBacklog）
會議准備：
1、邀請與會者（產品負責人、ScrumMaster、團隊所有成員）
2、既定產品Backlog
3、記錄任務時需要的卡片或貼紙
會議進程：
1、團隊成員從Backlog的各項問題中分出相應的任務。
2、確保考慮到工作中的所有細節
a. 編碼
b. 測試
c. 代碼評審
d. 會議
e. 學習新技術
f. 編寫文檔
3、如果任務需時超過一天：嘗試把該任務分割成幾個小任務。
4、如果團隊認為SprintBacklog中項過多：和產品負責人一起刪減Backlog中的問題。
5、如果團隊認為SprintBacklog中項過少：和產品負責人一起從產品Backlog中選出最重要問題，加入SprintBacklog中。
6、團隊確認Sprint目標。
會議結果：
1、Sprint目標和SprintBacklog對於公司內的所有人都是公開的
2、所有團隊成員都可以獲取SprintBacklog中的任務
產品負責人准備什么？講解什么？
1、會前准備：條目化的需求（用戶故事），優先級排序，最近1-2個迭代最希望看到的功能。
2、會上講解：較難以文字表述的內容。講解過程中團隊可以隨時發問，產品負責人要予以解答。若產品負責人感覺答案沒有想清楚，可以推遲故事的開發，或將故事分解為“已想清楚的”和“未想清楚的”，后者推遲到下一個迭代或更晚。
3、兩者的關系：准備活動類似於電影劇本編寫，它導致了這是不是一個好故事的基本問題；會上講解類似於導演說戲，它導致了這個故事我們能不能演好的問題。
4、一般一個團隊只有70%的工作可以進行正式工作，因此每個月安排15人天左右即為飽和，新團隊則可能低至10人天。
團隊怎樣估算？
1、共同估算：在估算前不應該指定誰將開發這個故事，而是以接收故事的小組為單位集體估算，每個人提出自己的看法，大家綜合。這樣才能以集體智慧完成任務。
2、在估算過程，產品負責人不能離開，因為很多估算差異問題來自於“做什么，做到什么地步”，產品負責人需要予以解答，而不是讓團隊按自己的理解去做。
3、共同估算的目的不是一個數字上的統一，而是用集體智慧和知識對“做什么，怎么做”達成共識。
4、共同估算是共同跟進的基礎，若不能共同估算，則后面的“每日站會”幾乎不可能正常進行，因為大家只關心自己曾經一起分析，思考，提問，設計乃至於爭論過的任務進展的怎樣了，是不是和自己想象的一樣。
5、共同估算的最佳方法是“撲克牌估算”。估算撲克是幾個潛在的任務承擔者（如某個功能小組）共同估算的方法，他們一起聽產品負責人講解，一起估算，以達到利用集體智慧解決問題的目的。
a. 每人各自估算后獨立出暗牌，聽口令一起開牌。
b. 數值最大者與最小者PK，其他人旁聽也可參與。
c. 討論結束后重新出牌與開牌。
d. 重復上述過程，知道結果比較接近。
其它會議：
在Sprint開始前，需確定各常規Scrum會議中的時間安排。
一般兩周的Sprint，建議其常規的Scrum會議時間安排如下：