題，我們可以限時讓他們討論出問題的根源和推薦出改進計劃，這樣我們一個能節省時間，更有價值的是可以調動每一個成員的積極參與度。
SMART的改進計劃
一個老調重彈的就是所有的改進計劃都必須是SMART的，SMART原則也不介紹了。這點說得容易，但做起來往往困難很大，大家非常容易產出一些類似建議一樣的東西，完全沒辦法執行。這里給大家一個小竅門，在每產出一個action的時候就問一下大家“這個action可以執行嗎？能判斷是否完成嗎？”，這樣往往就能幫忙準確判斷是否SMART。
避免產出過多改進計劃
當然還有一個陷阱就是改進計劃過多，到時候團隊根本沒有時間完成這么多的改進計劃，這個也需要排優先級；還有超出團隊能力范圍的改進要避免，不然也沒法落實。
2.5 結束會議
結束會議如果有必要的話我們可以簡單對本次會議的組織做個總結建議，可以幫助我們提高下次回顧會議的組織能力。
但我最喜歡的結束會議的方式是讓大家每個人通過一張紙片的形式感謝團隊里的一個人，并附上理由。我覺得這是一個很好的激勵團隊更多合作和相互幫助的好辦法。寫好紙片之后，我會請大家當眾宣讀一下卡片內容，并親手交給自己感謝的人，紙片格式如下：
三、提供幾個需要注意的地方
一般情況不建議團隊的經理參加回顧會議。這有悖于準備環節中提到的設立一個安全的環境，大家會擔心在會議上暴露團隊問題會對他們績效產生不好的影響。但也有一種情況我們需要經理在場，那就是團隊已經積累了很多非常嚴重的問題，但是經理可能都不大了解情況，大家都期盼的經理在場能聽到并推動解決這些問題。
會議產生的改進計劃怎么有效地跟蹤？一般我們建議把這些action之間放到團隊下個迭代的工作列表中，和普通開發工作一樣對待跟蹤，只有這樣才能有效地使得改進落地。
前后回顧會議產出相同或類似的改進計劃。這說明老問題一直沒有解決，有的時候會發現每次改進計劃都完成了，但是老問題仍然還在。一般如果想改進能力或是外部依賴的問題往往會導致這樣的情況，這些不像團隊自己的流程那樣能立竿見影，面對這樣的問題，團隊最好能計劃一些長期的（周期跨迭代的）改進計劃，下次回顧會議可以監控進展，而不是提重復的問題。
如果需要，別忘了在回顧會議前面簡單過一下上次回顧會議產出的改進計劃完成情況。
