Retrospective 是 Scrum 中定義的其中一種活動，主要是為了讓團隊定期回顧團隊與開發流程的狀況，並且提出改善的政策。

在本系列文的前幾天的文章，其實就是在講述相關概念，可以參考：

• 導入敏捷的過程也要敏捷
• 團隊一起定期聊聊近況吧
• 透過分享去激發團隊的討論
• 制定一個可落實的政策

官方的 Scrum Guides 本身並沒有針對 Retrospective 的實行方式有任何定義，只有講述其目的與活動的產出物。目的是為了

1. 檢視上次衝刺中，關於成員、關係、流程和工具的情況。
2. 找出並加以排序做得很好的重要事項（值得繼續保持），以及具有改善潛力的事項（還可以更好、或應該改善）。
3. 並在會議結束前，制定一個計畫、政策去改善團隊的工作方法。

如目的所述，所以我們在會議結束時，我們應該已經確定下一次衝刺要改善的地方與相關方法、政策。

雖然這些可以我們可以在任何時候針對覺得不好的地方提出改善，但回顧會議提供了一個正式的機會去專注在檢視團隊狀況以及調整上。而在會議中，我們也可以同步彼此對團隊的看法，並在經過交流與激辯中取得共識。

然而，雖然知道了回顧會議的目的，仍有許多人不知道該如何進行，而 Esther Derby 和 Diana Larsen 所著的《Agile Retrospectives: Making Good Teams Greats》中就有人出將會議分為五個階段去進行，分別是：

1. 設定會議基調（Set the stage）
2. 蒐集資料（Gather data）
3. 激發見解（Generate insight）
4. 做出決策（Decide what to do）
5. 結束會議（Close the retrospective）

關於這五個階段該如何進行，我會在後面幾天以實例解說。