1.評審會(Review Meeting)
a.小組向產品經理展示迭代成果。
b.產品經理給出產品的評價和反饋。
c.以用戶故事是否能成功交付來評價任務完成情況。
怎樣展開評審會？
答：敏捷開發采用時間盒(Time Boxing)的方法，即限定時間而不限定范圍。所以迭代不會延期，因為在迭代終點將放棄未完成的故事。
評審標准是什么？
答：整個故事是否已經達到交付標准，而不是從其中分解出來的任務完成了多少，因此若一個故事"差一點就完成了"，這種情況屬於未完成。
分析說明:
常常發生很多故事都已經開始開發了，但都差一點完成的現象。因此應按迭代內的優先級逐條開發和交付故事。
一般總是優先開發MoSCoW方法中必須完成和應該完成的故事，再考慮其他可以完成的故事。
一般在迭代計划會上設定每個故事的完成標准，如是否需要測試、是否需要考慮性能、是否需要說明文檔等等。
這些標准一般由項目組提前設定好。盡管有正式的評審會，但很多團隊還是習慣於在單個故事完成時，就讓產品負責人進行單個故事的評審，以確保交付時不會有"驚喜"。
評審會上發現的問題或改進將被累積到產品待開發項，也不會馬上或在下一個迭代中馬上開發，而是由優先級排序決定啥時開發。
2.反思會(Retrospective Meeting)
a.在每個迭代結束后，會召開簡短的反思會。
b.總結團隊在開發中哪些做的好，哪些做的不好，總結經驗。
c.指定改進計划
怎樣展開反思會？
答：一般在反思會上討論三個問題：我們在上個迭代中哪些事情做的好？哪些做的不好。好的繼續保持，不好的希望改進，有何改進計划。
分析說明:
經常出現一些問題多次被提到，但卻始終沒有解決，應該每次僅就1~3個關鍵問題作出可行的解決方案，在下一個迭代中執行改進。
"可行"的概念包括兩個含義:a.方法簡單、影響范圍小、見效快；b.目標不要激進，而要顯示可行、積少成多。
如果必要可以執行領導回避制度，即具有管理職能的人不參加反思會，即使這些人是產品負責人、項目經理、甚至是Scrum Master。