作者mark levison譯者張曉慶
《敏捷回顧: 讓團隊從優秀到卓越》的作者之一esther derby
，最近寫了一些提高敏捷回顧效果的技術：
把工作交給組員做- 站在房間最前面，什麼東西都由自己來寫，會妨礙團隊成員的主人翁意識。相反應該讓他們自己把想法寫在大postit便箋上（使用大號深色記號筆）──這會讓每個人積極參與，甚至會激勵沉默寡言的人提供想法。
忠實記錄- facilitator（或者scrummaster）要能正確領會組內成員的觀點，不要增加或刪改他們的觀點。
並行處理- 如果有2個或者以上的問題需要討論，就分成2個或者更多的小組，分別查詢根本原因。這能減少嘈雜聲音的干擾，從而加快解決問題。
讓組員作結論- facilitator（或者scrummaster）偶爾檢視一下團隊提供的原始資料，然後就宣布結論，沒有讓團隊自己做這個工作。實際上這表示facilitator並不重視團隊的意見。雖然團隊自己分析資料需要花費更長的時間，但是他們能得出更好的結論，並負責完成由此產生的行動任務。
測試一致程度- 短時間討論之後，可以測試看看團隊是否有了基本一致的意見（通常不是最終決定，有時只是乙個指示）。此時應該提出決定，一旦有人要求澄清，我們就用「五指拳(fist of five
)」測試觀點是否一致。這種方法裡面，手指的數量代表了支援的程度：5個 - 我就是這麼想的，並會積極引領變化；3個 - 團隊同意我也同意；1個 - 仍然有問題需要討論；拳 - 先不要表決，必須做更多討論才能達成最終意見。
george dinwiddie
建議把回顧會議中的行動任務寫到故事卡片上，並放到產品待開發列表中。這讓大家一直看見它們，更很有可能把它們做完。除此之外，他還建議，有時不應該解決最大或者最重要的問題──這可能會讓人心有餘悸。相反，讓團隊做他們有能力做的任務。
jo geske
建議到：
我們把重要事情直接貼到每個sprint燃盡圖上，而不是張貼到代表sprint的抽象的時間線：mike sutton則更進一步：「你可以把燃盡圖擴充套件成sprint的日曆，不僅僅能記錄完成的任務，而且包括障礙（如上所述）和關鍵的事件，這能讓你的回顧效果更好。」mike
繼續舉例說，有個團隊在回顧的時候就遇到了這樣的麻煩，他們不能很好地跟蹤障礙，以及會議上遇到的問題。
mike曾經使用的乙個方法是：把障礙張貼起來，包括時間、原因、以及其它的線索和上下文。問題解決後，在卡片上加上額外的註解。mike還發現，這不但對回顧有益，還能平衡事情的輕重緩急，對集中在每日站立會議有所幫助。
ilja preuss
說這個主意的確有趣，但它更關注於燃盡圖相關的事情。他需要採用一些其它技術，提出更多的小問題，以及sprint中做得較好的事情。最後，他會隨時間改變回顧會議的形式，這樣團隊能感到不落窠臼。
檢視英文原文：tips to improve retrospectives
敏捷 回顧會 如何通過強大的回顧來增強敏捷心跳
敏捷 回顧會 如果您在開放式組織中工作了一段時間，那麼您有時可能會聽到有人提到 衝刺 或 心跳 理解這些術語很簡單 制定乙個大目標，然後將其分解成小塊，以幫助您實現目標。該實踐源自敏捷開發及其各種 有趣的名字 風格，例如 scrum 和 看板 但是其基本邏輯很簡單 將大型工作分解成小的限時衝刺，然後...
我們的敏捷之路 回顧會議
我們引入敏捷已經超過2年了，經過長時間的不斷嘗試逐漸摸索出一套適應於我們團隊的方 即計畫會議 看板 每日站會 評審演示 回顧會議。這篇文章將著重介紹我們進行回顧會議的經驗教訓。回顧會議是scrum中最有價值的會議之一，雖然這個會議很重要，但是在實際的工作中我們會發現往往最容易被砍掉的也是這個會議。主...
印第安人的靈魂 敏捷回顧
印第安人在趕了3天路後，會停下來小憩一天，因為他要等著自己的靈魂跟上來。敏捷開發在經歷了一次迭代或者衝刺 sprint 後，也需要休整，以等待團隊的靈魂跟上來，這一過程被稱之為 敏捷回顧 agile retrospectives 敏捷回顧與專案總結會議不同，它並非專案結束之後的蓋棺論定，而是在專案過...