那該怎麼做Sprint回顧呢？
第一點是找出在上一個Sprint中做得好的地方，並繼續保持。分析那些導致成功的流程是非常重要 的，這樣我們纔能有意識地保持下去。只有團隊中的每一個 成員都清楚什麼纔是最佳實踐，纔能有效地鼓勵和保持這些實踐。除了可以鼓舞士氣外，還可以避免把回顧會議變成消極的抱怨會議。
第二點是找出 上一個 Sprint中需要改進的地方，以及對應的改進措施。回顧的目標就是持續不斷地改進，這也是敏捷開發的主要理念之一。讓我們想一想如何才能在下一個 Sprint中更加有效率，想一想在哪些方面如何做才能跟上一個Sprint不同。可以收集任何可以量化的數據，以便於做定量分析，推動改善。
其 他一些什麼事情是要特別注意?
首先，一定要明確這樣一個最高指導原則。即“無論我們發現了什麼，考慮到當時的已知情況、個人的技術水平和能 力、可用的資源，以及手上的狀況，我們理解並 堅信：每個人對自己的工作都已全力以赴”。
對團隊成員的績效評估，當然不能採用這樣的指導原則。我們現在談論的是 Sprint回顧，回顧的最終目的是學習，而不是審判。如果敏捷回顧沒有確定這樣的 “指導原則”，倡議團隊成員信任自己的夥伴，就會讓回顧會議成爲互相攻訐、互相推諉的批鬥大會，脫離了我們召開回顧會議的初衷。
“指 導原則”就是爲回顧會議豎立一個標杆，那就是在項目開發中沒有破壞者，沒有替罪羊，沒有關鍵人物，只有整個團隊的利益。雖然某個人或許在上一次迭代中 出現了錯誤，但我們會善意地相信此人之所以犯下錯誤，並非有意爲之或者消極怠工，而是囿於當時之識見、經驗、技能。我們的回顧會議必須指明這些錯誤，並試 圖總結出最佳實踐以避免在下一次迭代中犯下同樣的錯誤，而“指導原則”則能夠消除因爲錯誤的指出而給成員帶來的負疚感，消除同事之間可能因此出現的隔閡與 誤解。換句話說，回顧會議提出的所有批評都應該“對事不對人”。
組織Sprint 回顧的最簡單方法是找個白板紙，在上面註明“哪些項工作順利”，“哪些項不成功”或者“哪些項可以做得更好”，然後讓與會者在每一類別下增加一些條目。當 條目重複時，可以在該項旁邊計正字累計，這樣普遍出現的項目就一目瞭然了。最後團隊成員共同討論，找尋這些條目出現的根本原因，就如何在下一個 Sprint 中改進達成一致意見。
敏捷回顧的主要工作就是明確目標、持續改進、處理問題。 敏捷開發之所以採用迭代的方式，實際上是利用蠶食方式逐步完成開發任務。將一個宏偉的目標切割爲一 個個小目標，會給予團隊成員更大的信心，並且能夠更加清晰地明確目標。而每次迭代後的回顧，則使得團隊成員可以更加清晰地明確我們在這個征途中，已經走到 了哪裏，未來還有多遠的路程，就像印第安人那樣，等待自己的靈魂，否則就會不知身在何處了。