Retrospective 回顧會議是 Scrum 敏捷流程中，每個 Sprint 結束後團隊用來反思流程、找出改善行動的固定儀式。本文完整拆解 60 分鐘標準流程、5 大框架比較、心理安全建立技巧，以及行動追蹤的閉環機制，讓你的 Retro 不再流於形式。
什麼是 Retrospective 回顧會議？
Retrospective（簡稱 Retro）直譯是「回顧」，但它的核心精神不是「檢討誰做錯了什麼」，而是「我們如何一起變得更好」。這個區別非常關鍵——搞錯了，你的 Retro 就會變成沒人想參加的批鬥大會。
在 Scrum 框架中，Retrospective 是五大會議之一，固定在每個 Sprint 結束後舉行。它和其他四個會議各有分工：Sprint Planning 決定「做什麼」、Daily Scrum 同步「進度如何」、Sprint Review 展示「做出了什麼」，而 Retrospective 聚焦的是「我們的工作方式可以怎麼改善」。
很多人第一次搜尋「retrospective」時，會看到「retrospective study」（回溯性研究）的結果。這是醫學研究的術語，和我們討論的敏捷回顧會議完全不同。本文聚焦的是 Sprint Retrospective——敏捷團隊的持續改善儀式。
在開始之前，先破除三個最常見的誤解：
| 誤解 | 事實 |
|---|---|
| Retro 是批鬥大會，要找出誰搞砸了 | Retro 聚焦「流程」而非「個人」，目標是改善系統 |
| 每次 Retro 都差不多，走個形式就好 | 有效的 Retro 每次都應產出具體行動計劃 |
| Retro 結束就結束了 | 行動計劃沒有追蹤等於沒做，下次開場要先 review 上次決議 |
另一個常被混淆的是 Retrospective 和 Sprint Review 的差異。Sprint Review 面向利害關係人，展示的是「產品成果」；Retrospective 面向團隊內部，討論的是「工作流程」。兩者缺一不可，但解決的問題完全不同。
如果你的團隊正在導入 Scrum，理解這些會議的定位是第一步。我們團隊在實際跑 Sprint 時，會用 monday.com 的看板來管理整個 Sprint 週期，從 Planning 到 Retro 的所有產出都集中在同一個平台上，避免資訊散落各處。
Retrospective 的核心原則：心理安全是一切的前提
我們觀察過許多團隊的 Retro，發現一個殘酷的事實：多數 Retro 失敗的原因不是流程不對，而是沒人敢說真話。
當團隊成員擔心「說了會被記恨」「主管會不高興」「被認為在抱怨」，他們就會選擇沉默，或者只說一些無關痛癢的正面回饋。這樣的 Retro 開了等於沒開。
這就是為什麼敏捷社群有一條「最高指導原則」（Prime Directive），由 Norm Kerth 提出：
「無論我們發現了什麼，我們理解並真誠地相信，每個人在當時的情境下，以他們所知的知識、技能和資源，都已經盡了最大的努力。」
這句話不是雞湯。它的作用是在每場 Retro 開始前，明確設定一個前提：我們不是來追責的，我們是來改善流程的。 我們團隊每次 Retro 開場都會重申這條原則，即使已經跑了幾十場。
安全檢查（Safety Check）實作
在 Retro 正式開始前，花 2 分鐘做一次匿名安全檢查。方法很簡單：
- 請每位成員匿名投票，1-5 分評估「你在這場會議中願意坦誠發言的程度」
- 1 分 = 完全不敢說真話；5 分 = 可以暢所欲言
- 統計平均分數，公開結果（但不公開個人投票）
如果平均分低於 3 分，Scrum Master 需要調整策略：改用匿名書寫方式收集意見、縮小討論範圍（例如只討論流程問題，避開人際議題），或者先做一對一訪談再彙整。
我們曾經輔導一個 5 人產品團隊，第一次做安全檢查時平均分只有 2.2 分。Scrum Master 當場決定改用匿名便利貼，所有討論都不追問「這是誰寫的」。三個 Sprint 之後，安全分數提升到 3.8 分——因為團隊發現「說真話不會有後果」。這個信任是一場一場累積出來的。
如果你是團隊的主管或領導者，在 Retro 中最重要的事情就是「閉嘴聽」。你的一句「這不是問題吧」就能讓整場 Retro 的安全感歸零。
Sprint Retrospective 標準流程：60 分鐘完整拆解
以下是我們團隊實際使用的 60 分鐘 Retro 流程，適用於 2 週 Sprint、6-10 人團隊的標準配置。如果你的 Sprint 是 1 週，可以壓縮到 30-45 分鐘；4 週 Sprint 則可以延長到 90 分鐘。
關鍵概念是 Timebox——每個環節都有嚴格的時間限制。Retro 最怕的就是某個話題無限延伸，結果時間到了卻沒有產出任何行動計劃。
| 階段 | 時間 | 主持人動作 | 產出物 |
|---|---|---|---|
| Opening 暖身 | 5-10 分鐘 | 重申 Prime Directive、做安全檢查、review 上次行動計劃 | 團隊進入狀態 |
| 收集資料 | 15-20 分鐘 | 引導靜默書寫、分類便利貼、點票 | 分類後的議題清單 |
| 深度討論 | 20-25 分鐘 | 用 5 Whys 追問根因、引導全員參與 | 根因分析結果 |
| 行動計劃 | 10-15 分鐘 | 確認行動項目、指定負責人與期限 | 1-3 個具體行動項目 |
| Closing 收尾 | 5 分鐘 | 正向回饋、確認下次 Retro 時間 | 會議紀錄 |
Opening 暖身（5-10 分鐘）
暖身的目的不是「浪費時間聊天」，而是讓每個人都開口說話。心理學研究顯示，一個人在會議前 5 分鐘如果沒有發言，後面主動發言的機率會大幅下降。
一句話 Check-in 是最簡單的暖身方式：每個人用一句話描述自己對這個 Sprint 的感受。例如「這個 Sprint 我覺得像在跑馬拉松」或「終於把那個 bug 修好了，鬆一口氣」。
進階做法是 ESVP 問卷——請每個人匿名選擇自己今天的角色：
- Explorer（探索者）：想積極參與、發現新東西
- Shopper（購物者）：想聽聽看有沒有有用的資訊
- Vacationer（度假者）：人在心不在，但至少不用工作
- Prisoner（囚犯）：被迫來的，完全不想參加
如果 Prisoner 比例超過 30%，Scrum Master 需要正視這個問題——可能是 Retro 長期沒有產出實質改變，團隊已經失去信心。
遠端團隊可以用 Miro 白板 做 emoji check-in：在白板上放一排表情符號（😊😐😩🔥💤），每個人把自己的頭像拖到對應的位置。這比打字更直覺，也更容易打破遠端會議的沉默感。
收集資料（Data Gathering）（15-20 分鐘）
這個階段的核心是「先寫再說」。讓每個人靜默 5-7 分鐘，各自在便利貼上寫下想法，然後再一起分享。這樣做的好處是避免「錨定效應」——如果讓資深成員先發言，其他人的想法會不自覺地被帶著走。
最常用的框架是 Start / Stop / Continue：
- Start：我們應該開始做什麼？（目前沒在做的事）
- Stop：我們應該停止做什麼？（浪費時間或造成問題的事）
- Continue：我們應該繼續做什麼？（做得好的事）
實作步驟： 1. 每人靜默寫便利貼（每張只寫一個想法） 2. 輪流貼上白板並簡短說明 3. 主持人帶領分類（相似的歸在一起） 4. 全員點票（每人 3 票，投給最想討論的議題）
一個電商團隊用 Start/Stop/Continue 做 Retro 時，「Stop」欄位出現了 4 張便利貼都寫著「每日站會超時」。這個訊號非常清楚——團隊對站會效率有強烈不滿。他們後來設定了 15 分鐘的硬性 Timebox，超時就直接結束，改到會後個別討論。
如果你想用更系統化的方式管理這些議題，可以考慮在 ClickUp 的白板功能 上直接做分類和投票，討論結果可以一鍵轉成任務卡片，省去手動搬運的時間。
深度討論與根因分析（20-25 分鐘）
收集到議題後，針對票數最高的 1-2 個議題進行深度討論。這裡最重要的技巧是 5 Whys——連續追問「為什麼」，從表面症狀挖到根本原因。
舉例：
- 症狀：這個 Sprint 有 3 個 Story 沒有完成
- Why 1：因為開發時間不夠
- Why 2：因為需求在 Sprint 中途變更了
- Why 3：因為 PO 在 Sprint Planning 時還沒確認完需求
- Why 4：因為 PO 需要等客戶回覆，但客戶回覆很慢
- Why 5：因為我們沒有在 Sprint Planning 前設定「需求確認截止日」
根因找到了：缺少需求確認的截止機制。這比「開發時間不夠」具體得多，也更容易產出行動計劃。
除了 5 Whys，以下四個引導問題也非常實用：
- 「重來一次，你會怎麼做？」——引導團隊從「抱怨」轉向「解方」
- 「如果這個專案會失敗，原因會是什麼？」——用假設性問題降低防衛心，讓人更容易說出擔憂
- 「好的部分可以被複製到其他地方嗎？」——確保成功經驗不只是偶然
- 「現在的問題，之前是否就有跡象了？」——培養團隊的早期預警意識
當團隊很安靜怎麼辦？ 沉默通常有三種原因：
- 不安全：擔心說了會有後果 → 改用匿名方式
- 不知道說什麼：缺乏具體的引導問題 → 用上面四個問題逐一追問
- 不在乎：覺得說了也不會改變 → 這是最嚴重的，需要先讓之前的行動計劃真正落地，重建信任
善用流程圖來視覺化問題的因果關係，有時候畫出來比說出來更容易讓團隊達成共識。
決定行動計劃（10-15 分鐘）
這是整場 Retro 最關鍵的 10 分鐘。沒有行動計劃的 Retro，就是一場高級聊天。
行動計劃的黃金標準：
- 具體：不是「改善溝通」，而是「每週五下午 3 點，由 PM 發送週報給所有 stakeholder」
- 有負責人：每個行動項目指定一個人負責推動（不是「大家一起」）
- 有期限：明確的完成日期，通常是下一個 Sprint 結束前
每次 Retro 最多產出 1-3 個行動項目。 為什麼不能貪多？因為行動項目太多，等於沒有優先順序，最後一個都做不完。我們的經驗是：每次只做 1 個行動項目的團隊，執行率遠高於一次列 5 個的團隊。
用艾森豪矩陣的思維來篩選：哪個行動項目是「重要且緊急」的？先做那一個就好。
Closing 收尾（5 分鐘）
收尾不要草草結束。花 2 分鐘做一個「全隊 MVP 肯定環節」：每個人說一句感謝某位隊友的話。這不是矯情——正向回饋能強化團隊凝聚力，也讓 Retro 不只是「找問題」，還有「慶祝成功」。
最後，確認：
- 行動計劃已記錄（誰負責、什麼時候完成）
- 下次 Retro 的時間已排定
- 下次 Retro 開場第一件事：review 這次的行動計劃執行狀況
五大 Retrospective 框架比較：選對格式事半功倍
如果你的團隊每次 Retro 都用同一個框架，大概跑到第五次就會開始覺得無聊。框架疲乏是 Retro 失效的常見原因之一。以下五種框架各有適用情境，輪替使用可以保持新鮮感。
Start / Stop / Continue（新手首選）
這是最直覺的框架，適合剛開始做 Retro 的團隊。三個欄位清楚明瞭，不需要額外解釋。
限制：因為太簡單，容易停留在表面。團隊跑了幾次之後，可能會覺得「每次都在講一樣的事」。這時候就該換框架了。
4Ls（Liked / Learned / Lacked / Longed For）
- Liked：這個 Sprint 中你喜歡什麼？
- Learned：你學到了什麼？
- Lacked：缺少了什麼？
- Longed For：你希望未來能有什麼？
4Ls 比 SSC 多了「學習」和「期望」的維度，適合重視團隊成長的組織。特別是「Learned」欄位，能幫助團隊養成持續學習的心態，而不只是盯著問題看。
Mad / Sad / Glad（情緒導向）
用情緒分類取代理性分類。適合在高壓 Sprint 結束後使用——當團隊經歷了趕死線、重大 bug、客戶投訴等壓力事件，先讓情緒有出口，再來談改善。
注意：這個框架需要較高的心理安全感。如果團隊安全檢查分數低於 3 分，不建議使用。
Sailboat（帆船比喻，適合遠端）
把團隊比喻成一艘帆船：
- 風（Wind）：推動我們前進的力量
- 錨（Anchor）：拖慢我們的阻力
- 礁石（Rocks）：前方的風險
- 島嶼（Island）：我們的目標
視覺化的比喻讓討論更活潑，特別適合遠端團隊在白板工具上操作。我們團隊用 Miro 的帆船模板 跑過幾次，發現「礁石」欄位特別能引出平常不會主動提起的潛在風險。
Timeline Retrospective（適合長期專案里程碑後）
在白板上畫一條時間軸，標出 Sprint 中的重要事件，然後在每個事件下方標註「高點」和「低點」。適合 Sprint 較長（3-4 週）或專案里程碑結束後使用。
這個框架的優勢是能看到事件之間的因果關係——「原來那個 bug 是因為前一週的需求變更造成的」。
| 框架 | 適用情境 | 團隊規模 | 難易度 | 特色 |
|---|---|---|---|---|
| Start / Stop / Continue | 新團隊、第一次做 Retro | 任何規模 | ★☆☆ | 最直覺，零學習成本 |
| 4Ls | 重視學習與成長的團隊 | 5-15 人 | ★★☆ | 多了學習維度 |
| Mad / Sad / Glad | 高壓 Sprint 後 | 5-10 人 | ★★☆ | 先處理情緒再談改善 |
| Sailboat | 遠端團隊、需要視覺化 | 5-12 人 | ★★☆ | 比喻式討論更活潑 |
| Timeline | 長 Sprint 或里程碑後 | 6-15 人 | ★★★ | 能看到事件因果關係 |
Scrum Master 的主持技巧：讓 Retro 不淪為形式
Scrum Master 在 Retro 中扮演三個角色：引導者（讓討論聚焦）、守時者（嚴格 Timebox）、心理安全守護者（確保每個人都能安心發言）。
以下是我們觀察到最常見的五個主持失誤，以及修正方式：
失誤一：讓資深成員主導發言。 資深成員一開口，其他人就不敢說不同意見。修正方式：先靜默書寫，再輪流發言（從最資淺的開始）。
失誤二：跳過暖身直接進主題。 覺得暖身浪費時間，結果整場會議只有 2-3 個人在講話。修正方式：即使只有 3 分鐘，也要讓每個人開口說一句話。
失誤三：行動計劃沒有指定負責人。 「大家一起改善」等於沒有人負責。修正方式：每個行動項目必須有一個名字、一個日期。
失誤四：超時不 Timebox。 某個話題聊得太開心，結果沒時間做行動計劃。修正方式：設定計時器，時間到就切換，未完成的議題記錄下來，下次再討論。
失誤五：上次行動計劃沒有 review。 這是最致命的——如果團隊發現「上次說要做的事根本沒人追蹤」，他們就不會再認真對待 Retro。修正方式：每次 Retro 開場前 3 分鐘，固定 review 上次的行動項目。
如何處理「批評對事不對人」
當有人說「小明每次都遲交」，主持人需要立刻轉換框架：「我聽到的是交付時程的問題。我們來看看是什麼流程上的原因導致延遲？」把焦點從「人」轉到「流程」。
實用話術：
- 「謝謝你提出來。我們把這個轉成流程問題來看——是什麼環節可以調整？」
- 「這個觀察很重要。如果不是個人因素，還有什麼系統性的原因？」
保守組織文化下的突破策略
在台灣許多傳統產業中，「開會檢討」往往等於「找人背鍋」。要在這種文化下導入 Retro，不能一步到位。
一個製造業的 Scrum Master 分享了他的策略：第一個月，他不叫它「Retrospective」，而是叫「流程優化討論會」。他只討論一個具體的流程問題（例如「為什麼這批訂單延遲了 3 天」），用數據呈現問題，讓主管看到「這不是在怪人，是在找系統問題」。三個月後，主管主動問：「這個會議可以固定每兩週開一次嗎？」
如果你正在推動組織的數位轉型，Retro 是一個很好的切入點——它不需要大規模的工具導入，只需要一個白板和 60 分鐘。
行動追蹤：Retro 結束後才是真正的開始
根據我們的觀察，大約 80% 的 Retro 行動計劃最後都沒有被執行。原因通常不是團隊不想做，而是「沒有人追蹤」。
行動追蹤需要三個層次：
第一層：記錄在哪裡？ 行動計劃不能只存在會議紀錄裡。它需要被轉化成一張任務卡片，放在團隊每天都會看到的地方。我們團隊的做法是在 monday.com 的看板 上建立一個「Retro 行動追蹤」群組，每個行動項目就是一張卡片，包含：問題描述、行動內容、負責人、完成期限、狀態。
（推薦試試 monday.com 的免費方案，我們團隊實際使用後發現它的自動化功能特別適合追蹤行動項目——設定一條規則：「狀態超過期限未更新，自動通知負責人」，就不需要 Scrum Master 手動追蹤。）
第二層：誰負責追蹤？ 理想狀態是團隊自治——每個人對自己的行動項目負責。但在初期，Scrum Master 需要扮演「溫柔的提醒者」角色，在 Sprint 中期主動問一句「上次的行動項目進度如何？」
第三層：閉環機制。 每次 Retro 開場前 3 分鐘，固定 review 上次的行動計劃。完成的打勾慶祝，未完成的討論原因——是優先順序改變了？還是行動計劃本身不夠具體？
Action Item Card 範本
每張行動卡片應包含以下欄位：
| 欄位 | 範例 |
|---|---|
| 問題描述 | 每日站會經常超過 15 分鐘 |
| 行動內容 | 設定 15 分鐘計時器，超時議題移到會後討論 |
| 負責人 | Scrum Master（小陳） |
| 完成期限 | 下個 Sprint 結束前（11/15） |
| 狀態 | 進行中 / 已完成 / 已取消 |
一個軟體開發團隊用 Notion 建立 Retro 行動追蹤資料庫，每次 Retro 結束後直接在資料庫新增項目。三個月後回顧，他們發現 12 個行動項目中有 9 個已完成，改善率 75%——遠高於之前「寫在白板上然後忘記」的時期。
Retrospective 工具推薦：線上與線下場景完整比較
選擇 Retro 工具時，考慮三個維度：團隊規模、遠端還是實體、預算。以下是我們實際測試過的工具。
monday.com（行動追蹤首選）
嚴格來說，monday.com 不是專門的 Retro 工具，但它在「行動追蹤」這個環節表現最強。Retro 的價值不在會議本身，而在會後的執行——而 monday.com 的看板、自動化、Dashboard 功能讓行動追蹤變得非常順暢。
我們團隊的實際做法：在 monday.com 上建立一個「Sprint Retro」看板，每個 Sprint 的行動項目都是一張卡片。設定自動化規則：「當狀態改為『已完成』時，自動通知全團隊」。這樣每個人都能看到改善正在發生，也強化了「Retro 是有用的」這個信念。
免費方案最多 2 位使用者，不需要信用卡。付費方案從 NT$288/月/人起。
Miro（遠端 Retro 白板首選）
Miro 是目前最多團隊用來跑遠端 Retro 的白板工具。它內建了多種 Retro 模板（Start/Stop/Continue、Sailboat、4Ls 等），開箱即用。
操作方式：開啟 Retro 模板 → 設定計時器 → 團隊成員各自在便利貼上寫想法 → 拖曳分類 → 用投票功能點票。整個流程在一個畫面上完成，不需要切換工具。
免費方案可建立 3 個白板，適合小團隊試用。付費方案約 NT$400/月/人。
Retrium（專為 Retrospective 設計）
Retrium 是市場上少數專門為 Retro 設計的工具。它的優勢是結構化流程——從暖身、收集資料、投票、討論到行動計劃，每個步驟都有引導。適合 Scrum Master 經驗較少、需要工具幫忙引導流程的團隊。
付費方案約 NT$700/月（最多 10 人），沒有免費方案但有試用期。
EasyRetro（輕量免費）
如果你的團隊預算有限、只需要最基本的功能，EasyRetro（前身為 FunRetro）是不錯的選擇。免費方案支援 3 個看板、無限成員。介面簡潔，學習成本幾乎為零。
適合 3-5 人的小團隊，或者想先試試看 Retro 的團隊。
實體工具（便利貼 + 白板）
別小看便利貼的力量。同地辦公的團隊用實體白板做 Retro，有一種線上工具無法取代的「儀式感」。站在白板前面、親手貼上便利貼、用馬克筆畫圈分類——這些動作本身就能提升參與感。
材料清單：
- 白板或大張壁報紙
- 三色便利貼（對應框架的三個欄位）
- 馬克筆（每人一支）
- 計時器（手機即可）
- 圓點貼紙（用於投票）
| 工具 | 適用場景 | 價格（NT$/月/人） | 免費方案 | 特色 |
|---|---|---|---|---|
| monday.com | 行動追蹤、Sprint 管理 | NT$288 起 | 2 人免費 | 自動化追蹤最強 |
| Miro | 遠端 Retro 白板 | NT$400 起 | 3 個白板 | 模板豐富、視覺化 |
| Retrium | 結構化 Retro 流程 | NT$700（10 人） | 試用期 | 專為 Retro 設計 |
| EasyRetro | 小團隊、預算有限 | 免費 | 3 個看板 | 零學習成本 |
| 實體白板 | 同地辦公 | 便利貼費用 | — | 儀式感最強 |
你是哪種團隊？
- 3-5 人、剛開始做 Retro → 先用 EasyRetro 免費版，熟悉流程
- 5-15 人、遠端或混合辦公 → Miro 做 Retro 白板 + monday.com 追蹤行動
- 技術團隊跑完整 Scrum → ClickUp 整合 Sprint 管理與 Retro 追蹤
- 15 人以上、需要跨團隊追蹤 → monday.com 企業方案，用 Dashboard 彙整多個團隊的改善進度
結論
Retrospective 回顧會議是敏捷團隊持續改善的引擎，但它的價值不在「開會」本身，而在會後的行動是否真正落地。
回顧本文重點：
- Retro 的核心是「持續改善」而非「追責」——每場開始前重申 Prime Directive，建立心理安全感
- 60 分鐘標準流程：暖身 → 收集資料 → 深度討論 → 行動計劃 → 收尾，每個環節嚴格 Timebox
- 五大框架輪替使用：Start/Stop/Continue 適合新手、Mad/Sad/Glad 適合高壓後、Sailboat 適合遠端團隊
- 行動計劃要具體：有負責人、有期限、每次最多 1-3 個，寧可少做但做到
- 閉環追蹤是關鍵：用工具記錄行動項目，下次 Retro 開場先 review 上次決議
你的下一步行動：從下一個 Sprint 結束後，用 Start/Stop/Continue 框架跑一場 60 分鐘的 Retro。如果你需要一個地方來追蹤行動計劃的執行狀況，可以在 monday.com 上用看板建立「Retro 行動追蹤」群組——免費方案不需要信用卡，10 分鐘就能設定好你的第一個追蹤看板。
Retrospective 回顧會議常見問題
Retrospective 中文怎麼說？和 Sprint Review 有什麼不同？
Retrospective 中文常見翻譯為「回顧會議」或「自省會議」。它和 Sprint Review 最大的差異在於：Sprint Review 面向利害關係人，展示「產品做了什麼」；Retrospective 面向團隊內部，討論「工作流程怎麼改善」。兩者在 Scrum 中是不同的會議，不能互相取代。
Retrospective 多久做一次？每次要多長時間？
標準做法是每個 Sprint 結束後做一次。2 週 Sprint 建議 60 分鐘，1 週 Sprint 可壓縮到 30-45 分鐘，4 週 Sprint 則可延長到 90 分鐘。重點是保持固定節奏，不要因為「這個 Sprint 沒什麼問題」就跳過。
非 Scrum 團隊也可以做 Retrospective 嗎？
完全可以。Retro 的本質是「定期反思工作方式並找出改善行動」，這個概念不限於 Scrum。行銷團隊可以在每次活動結束後做 Retro，業務團隊可以每月做一次。只要團隊願意花時間反思，任何組織都能受益。如果你的團隊還沒有固定的企劃流程，Retro 是一個很好的起點。
Retrospective reporting 是什麼？要怎麼記錄？
Retrospective reporting 指的是 Retro 會議的記錄與追蹤文件。最基本的格式包含：會議日期、參與者、討論議題摘要、行動計劃（含負責人與期限）、上次行動計劃的執行狀態。建議用專案管理工具建立固定模板，每次 Retro 後直接填寫，避免資訊遺失。
Retrospective study 和 Retrospective meeting 是一樣的東西嗎？
不一樣。Retrospective study（回溯性研究）是醫學和社會科學的研究方法，透過回顧過去的數據來分析因果關係。Retrospective meeting（回顧會議）是敏捷開發中的團隊儀式，用來反思工作流程並找出改善行動。兩者名稱相似但領域完全不同。
團隊只有 3 個人，還需要做 Retro 嗎？
需要，而且 3 人團隊做 Retro 反而更容易有效果。人少意味著每個人的聲音都能被聽到，討論更聚焦，行動計劃更容易落地。3 人團隊的 Retro 可以縮短到 20-30 分鐘，用最簡單的 Start/Stop/Continue 框架即可。重點不是人數多寡，而是「有沒有固定的時間來反思和改善」。
