Sprint Retrospective

Scrum 在每個 Sprint 結束時提供兩個檢視與調適機會：Sprint Review 檢視產品，Sprint Retrospective 檢視流程。本章深入介紹 Sprint Retrospective 的目的、參與者、事前準備、執行活動，以及最關鍵的——活動後的跟進執行。

概覽#

Figure 22.1: Edward Bear illustrating the need for a retrospective

Sprint Retrospective 讓整個 Scrum 團隊有機會停下來思考：

團隊在時間箱內自由檢視正在發生的事、分析工作方式、找出改善方法並制定實施計畫
所有影響團隊產出的因素都可以被檢視與討論：流程、實踐、溝通、環境、工件、工具等

Sprint Retrospective 是 Scrum 框架中最重要卻最不被重視的實踐。有些人誤認為它佔用了「真正的」設計、建構與測試時間，但它實際上是 Scrum 持續改善的關鍵貢獻者。

Figure 22.2: When the sprint retrospective happens

最簡單的 Retrospective 形式就是團隊討論三個問題：

這個 Sprint 做得好的、想繼續做的是什麼？
這個 Sprint 做得不好的、應該停止的是什麼？
我們應該開始做或改善什麼？

參與者#

全體 Scrum 團隊必須出席：Development Team、ScrumMaster、Product Owner
ScrumMaster 既是流程的一部分，也是流程的權威——不是告訴團隊如何改變，而是指出團隊未遵守自己約定流程之處
Product Owner 應參加（除非信任或安全感不足）——作為需求流入團隊的管道，如果需求流程有問題，沒有 Product Owner 在場就難以有效討論改善方案

非 Scrum 團隊成員（利害關係人、經理）只應在被團隊邀請時才出席。如果團隊成員因為外部人員在場而無法坦誠揭露問題，Retrospective 將失去其效力。團隊必須感到安全。

事前準備（Prework）#

Figure 22.3: Sprint retrospective prework

定義 Retrospective 焦點#

預設焦點：審視當前 Sprint 使用的流程的所有相關面向
特定焦點範例：
- 如何改善團隊的 TDD 技能
- 為什麼我們建構出自以為客戶想要的東西，但客戶看到時卻常覺得被誤解
確定焦點後可判斷是否需要邀請非 Scrum 團隊成員

對於長期運作的高績效團隊，更聚焦的 Retrospective（深入特定問題的根因分析）可以持續從中提取價值，避免「為了流程而流程」的感覺。

選擇練習活動#

典型的 Retrospective 包含以下練習：

建立並挖掘 Sprint 事件時間線
腦力激盪洞察
分組與投票

也可根據焦點或參與者變化練習方式以保持新鮮感。有些需要數據或材料的練習最好在事前準備時確定。

收集客觀數據#

在 Retrospective 開始前收集硬數據（非意見）：事件發生時間、未完成的 PBI 數量、Sprint 燃起圖等
此時只收集不分析——確保數據在 Retrospective 時可用

規劃結構#

通常安排在每個 Sprint 結束時的同一地點、日期和時間
時長：至少 60 分鐘；兩週 Sprint 建議約 1.5 小時
地點可選在團隊區域（方便存取看板數據）或外部場所（降低情緒飽和度，讓人更自在發言）
促進者：通常由 ScrumMaster 擔任，但也可由其他團隊成員或外部中立促進者擔任；跨團隊的 ScrumMaster 互相促進各自團隊的 Retrospective 也是好做法

執行方式#

Figure 22.4: Sprint retrospective activity

輸入與輸出#

輸入	輸出
Retrospective 焦點	具體改善行動
練習活動與材料	洞察待辦清單（Insight Backlog）
客觀數據	改善的團隊凝聚力
主觀數據（每位參與者的個人感受）
先前的 Insight Backlog

第一步：營造氛圍（Set the Atmosphere）#

讓人們感到安全表達意見，不懼報復
建立基本規則（Working Agreement）：聚焦組織系統與流程，而非針對個人
建立主動參與的先例——開場讓每人用幾句話表達當前感受或能量水準

第二步：建立共享脈絡（Share Context）#

Figure 22.5: Aligning perspectives to create a shared context

同一事件，不同人可能有截然不同的詮釋。需要將個人視角對齊為團隊共享視角：

先以客觀數據（已承諾的 PBI、完成的 PBI、缺陷數等）建立事實基礎
再揭露並討論主觀數據（個人對 Sprint 的感受與詮釋）

事件時間線（Event Timeline）#

在牆面或白板上畫時間線，參與者用便利貼按時間順序標記 Sprint 中的重要事件
可用不同顏色代表不同事件類型（技術/組織/個人）或感受（正面/中性/負面）

情緒地震圖（Emotions Seismograph）#

每位參與者畫出 Sprint 期間的情緒或能量水準曲線
通常畫在事件時間線下方，便於視覺化關聯
將共享脈絡從客觀數據（發生了什麼）擴展到主觀數據（團隊的感受如何）

第三步：識別洞察（Identify Insights）#

Figure 22.8: Retrospective insight card wall

在共享脈絡建立後，參與者挖掘數據以識別改善洞察，需要系統層級（全局）的視角：

什麼做得好？
什麼做得不好？
哪些地方有機會做不同的事？

參與者將洞察寫在卡片上，放到共享牆面上，然後進行組織：

方式一：靜默分組（Silent Grouping）

Figure 22.9: Insight cards clustered into similarity groups

不經口頭討論，參與者透過擺放和移動卡片來協作建立分組
時間效率高且有效

方式二：預設類別

Figure 22.10: Insight cards placed into predetermined groups

事先將牆面分為「繼續做的」「停止做的」「嘗試的」等類別
參與者在建立卡片時直接放入適當類別

第四步：決定行動（Determine Actions）#

洞察是改善的想法與認知；要從中提取長期價值，需要轉化為具體可執行的行動。

選擇優先洞察#

Retrospective 通常識別出的改善洞察遠多於團隊能在短時間內消化和執行的量。

Dot Voting（圓點投票）：

每位參與者獲得 3-5 個彩色圓點
同時將圓點貼在認為最高優先的洞察卡片上
可集中貼在一張或分散多張
獲得最多圓點的洞察優先處理

重要性與能量不一定相同。即使某個洞察很重要，如果團隊對執行它沒有動力，現在可能不是好時機。選擇團隊有能量去改善的洞察，更有可能產生具體行動。

決定具體行動#

行動類型	範例與做法
任務級工作	例如「讓建構伺服器在 build 壞掉時寄 email」→ 指派特定團隊成員在下個 Sprint 執行
行為改變	例如「尊重彼此、準時出席 Daily Scrum」→ 不需要消耗團隊產能
障礙移除	例如需要第三方軟體最新版本 → ScrumMaster 與採購部門合作解決
需要探索的洞察	如果尚不理解根因，行動可以是「在下個 Sprint 調查並收集數據」

flowchart TD
    A[挖掘共享脈絡] --> B[撰寫洞察卡片]
    B --> C[分組歸類]
    C --> D[圓點投票排序]
    D --> E[選擇優先洞察]
    E --> F{行動類型?}
    F -->|任務級工作| G[放入 Sprint Backlog]
    F -->|行為改變| H[團隊自我約定]
    F -->|障礙移除| I[放入 ScrumMaster\n障礙清單]
    F -->|需要探索| J[放入 Insight Backlog\n下次再議]

需要 Product Owner 參與決定團隊分配多少時間在改善行動上——花時間改善意味著可開發功能的時間減少。如果不明確分配時間，改善行動很可能不會被執行。

洞察待辦清單（Insight Backlog）#

保存在 Retrospective 中識別但無法立即處理的洞察
下次 Retrospective 時可作為候選項與新洞察一起排序
有些團隊選擇丟棄未被選中的洞察——如果真的重要，下次 Retrospective 還會被再次識別

第五步：關閉活動（Close the Retrospective）#

回顧行動：描述每個已承諾的行動項目及負責人
表達感謝：感謝參與者的貢獻，特別是非 Scrum 團隊成員的參與
改善 Retrospective 本身：花幾分鐘收集改善 Retrospective 做法的建議——Retrospective 本身也應受到檢視與調適

跟進執行（Follow Through）#

確保 Retrospective 中的決議不只停留在會議室內：

行動類型	跟進方式
行為類行動	由團隊成員與 ScrumMaster 重申和強化
任務類行動	在下個 Sprint Planning 先將改善任務放入 Sprint Backlog，再引入新功能；相應調整可用產能
障礙類行動	放入 ScrumMaster 的障礙清單；外部團隊負責的放入其對應的 backlog，由 ScrumMaster 追蹤

flowchart TD
    A[Retrospective 產出行動] --> B{行動類型}
    B -->|行為類| C[團隊自我強化\n每日提醒]
    B -->|任務類| D[放入 Sprint Backlog\n作為工作項目追蹤]
    B -->|障礙類| E[放入障礙清單\nScrumMaster 持續追蹤]

不要將「改善計畫」與 Sprint 工作分開管理！ 兩條線的做法幾乎總是導致改善計畫被功能驅動的 Sprint 計畫壓過。要確保改善行動真的被執行，必須整合，而非分離。