迭代計劃會議（不超過1個小時）

1.   需求人員與測試人員對將要到來的迭代的故事進行精化，新增驗收條件，並對驗收點著重表現。每一個故事進行凍結。（提前準備）

2.   迭代計劃會在每個迭代的第一天召開，目的是選擇和評估本次迭代的工作項。

3.   PO或需求人員逐條講解最重要的產品功能，與開發達成共同理解，開發人員需要提前瞭解需求，並整理疑問點。

4.   開發人員：把所有可能要進到迭代的故事卡片分成兩堆，石頭故事（還不能開發，需求不清）和鑽石故事（需求的要求點都很清楚）

5.   需求人員（SA）和測試：對開發人員諾到石頭部分的卡片進行解釋，儘可能放到鑽石部分（3，4，5點一共30分鐘）

6.   開發團隊共同估算故事所需的工作量。直到本次迭代的工作量達到飽和。（任務分配一定要在估算和方案設計之後）

7.   PO參與估算討論並回答與需求相關的問題，但不干涉估算結果。（6，7一共20分鐘）

8.   團隊進行方案設計。

Tips：方案設計需要考慮關聯絡統是否在本次迭代週期內可以支援，是否開發任務的前置條件已經進入可測試階段，限制在製品數量（控制並行任務）。

9.   明確任務責任人（包括開發、測試、資料）和任務完成時間點。

產品負責人準備什麼？講什麼？

準備工作：條目化需求(使用者故事)、優先順序排序、最近1~2個迭代最想看到的功能。會前的準備工作十分重要，可以幫助產品負責人清理頭緒，不至於在迭代期內頻繁提出變更、增加、修改故事。

會議講解：難以用文字描述的內容。在講解的過程中，團隊可以隨時提問，產品負責人要給予解答。若產品負責人感覺暫時無法講解清楚，可以推遲此故事的開發，或將故事分解為"已想清楚"和"未想清楚"，後者推遲到下一個迭代或更晚。

團隊怎麼估算？

1.共同估算：在估算前不應該指派由誰開發某個故事，而是以接受故事的小組為單位集體估算，每個人提出自己的看法，大家綜合，這樣才能以集體的智慧完成任務。

2.在估算全過程，產品負責人不能離開，因為很多估算差異問題來自於"做什麼，做到什麼程度"，產品負責人需要給予解答，而不是讓團隊自己理解去做。

3.共同估算為的不是一個數字上的統一，為的是用集體的智慧和只是對"做什麼，怎麼做"達成共識。

4.共同估算，是共同跟進的基礎，若不能共同估算，則後面的【每日立會】幾乎不可能正常進行，因為大家只會關心自己曾經一起分析、思考、提問、設計甚至爭論過的任務的進展怎麼樣了。

計劃會議常見問題（師傅帶徒弟模式團隊）：

1.為什麼任務要分給組而不是分給個人？

不分給個人，這樣可以使得每一個人不得不全面考慮，對此有所瞭解，日後及時他不擔當此模組，他對這個模組也有了解。

2.為什麼不讓最後領取任務的人估算？

因為他可能不知道某些程式碼的可用性、不知道某軟體不可用、不同Template、......，從而選擇了錯誤的實現方法。

3.為什麼不讓師傅估算,大家直接採納呢?

師傅的想法通常是徒弟所理解不了的。共同估算就是讓大家在思考中，對照自己的實現方法和師傅的差異的過程。

4.PO怎麼還參加？不是不讓別人參與嗎？

PO可以挑戰估算，比如"這需要那麼久嗎"，但是要有理有據。其實實踐中更容易看到的是團隊往往過於樂觀激進，PO反而可以讓他們意識完整的需求和要求，做出更現實的估算。估算不準去，PO也有責任。