１.迭代計划會在每個迭代的第一天召開，目的是選擇和評估本次迭代的工作項。
２.產品負責人逐條講解最重要的產品功能。
３．開發團隊共同估算故事所需的工作量。直到本次迭代的工作量達到飽和。
４.產品負責人參與討論並回答與需求相關的問題，但不干涉估算結果。
產品負責人准備什么？講什么？
准備工作：條目化需求(用戶故事)、優先級排序、最近1~2個迭代最想看到的功能。會前的准備工作十分重要，可以幫助產品負責人清理頭緒，不至於在迭代期內頻繁提出變更、增加、修改故事。
會議講解：難以用文字描述的內容。在講解的過程中，團隊可以隨時提問，產品負責人要給予解答。若產品負責人感覺暫時無法講解清楚，可以推遲此故事的開發，或將故事分解為"已想清楚"和"未想清楚"，后者推遲到下一個迭代或更晚。
一瓣地，一個團隊只有70%的工作可以進行正常工作，因此，每個人月安排15天左右即為飽和，新團隊則最低10人天左右。
團隊怎么估算？
1.共同估算：在估算前不應該指派由誰開發某個故事，而是以接受故事的小組為單位集體估算，每個人提出自己的看法，大家綜合，這樣才能以集體的智慧完成任務。
2.在估算全過程，產品負責人不能離開，因為很多估算差異問題來自於"做什么，做到什么程度"，產品負責人需要給予解答，而不是讓團隊自己理解去做。
3.共同估算為的不是一個數字上的統一，為的是用集體的智慧和只是對"做什么，怎么做"達成共識。
4.共同估算，是共同跟進的基礎，若不能共同估算，則后面的【每日立會】幾乎不可能正常進行，因為大家只會關心自己曾經一起分析、思考、提問、設計甚至爭論過的任務的進展怎么樣了。
5.共同估算的最佳方法是"撲克牌估算法"，這貌似很想個小游戲，但卻是"Delphi"估算的一個快速的方法，同時實現了匿名性和高效性。
"撲克牌估算法",是幾個潛在的任務承擔者(比如某個功能小組)共同估算的方法，他們一起聽產品負責人講解，一起估算，以達到利用集體智慧解決問題的目的。
算法思想:每人各自估算后獨立出暗牌，聽口令一起出牌；然后進行數值大的跟數值小的進行PK，闡明各自的原因，其他成員旁聽，也可以參與。討論結束后，重新出牌、開牌。重復以上的過程，直到結果比較接近。
常見問題:(一個項目經理/小組長帶新人的師徒制度中)
1.為什么任務要分給組而不是分給個人？
不分給個人，這樣可以使得每一個人不得不全面考慮，對此有所了解，日后及時他不擔當此模塊，他對這個模塊也有了解。
2.為什么不讓最后領取任務的人估算？
因為他可能不知道某些代碼的可用性、不知道某軟件不可用、不同Template、......，從而選擇了錯誤的實現方法。
3.為什么不讓師傅估算,大家直接采納呢?
師傅的想法通常是徒弟所理解不了的。共同估算就是讓大家在思考中，對照自己的實現方法和師傅的差異的過程。
4.PO怎么還參加？不是不讓別人參與嗎？
PO可以挑戰估算，比如"這需要那么久嗎"，但是要有理有據。其實實踐中更容易看到的是團隊往往過於樂觀激進，PO反而可以讓他們意識完整的需求和要求，做出更現實的估算。估算不准去，PO也有責任。