Sprint 結尾有兩個重要的檢視與調適活動：Sprint Review 關注產品本身，Sprint Retrospective 則關注流程。本章聚焦於 Sprint Review 的目的、參與者、事前準備與執行方式。

概覽#

Figure 21.1: When the sprint review happens

Sprint Review 發生在 Sprint Execution 之後、Sprint Retrospective 之前（或偶爾之後），是 Scrum 框架中最重要的學習迴路之一：

  • 讓所有對產品開發有影響力的人有機會檢視與調適已建構的成果
  • 提供對產品當前狀態的透明觀察，包括任何「不方便的真相」
  • 因為 Sprint 很短，這個迴路是快速的，允許頻繁的路線修正

如果將回饋推遲到很久之後，並假設一切按計畫進行，最終很可能得到的是驚訝、失望和挫折。Sprint Review 的價值在於頻繁、及時地獲取回饋。

參與者#

Sprint Review 應讓所有相關人員參與，以提取最高價值：

來源說明
Scrum 團隊Product Owner、ScrumMaster、Development Team 全員出席，確保聽到相同回饋並能回答問題
內部利害關係人業務負責人、高層主管、經理——親眼看到進展以便建議路線修正
其他內部團隊銷售、行銷、支援、法務、合規及其他開發團隊，提供專業領域回饋或同步工作
外部利害關係人客戶、使用者、合作夥伴——提供直接（而非代理）回饋

除非有充分理由不邀請某人，否則建議廣泛邀請，讓人們自行「用腳投票」。如果有需要限制出席的情況，可建立一個核心小組每次必出席，再針對特定 Sprint 額外邀請特定群組。

事前準備（Prework）#

Figure 21.2: Sprint review prework

雖然 Sprint Review 是一個非正式活動，但 Scrum 團隊仍有一些最低限度的準備工作：

決定邀請名單#

  • 目標是將正確的人帶進會議室以提取最高價值
  • 可建立核心出席群組，再視每個 Sprint 的需求額外邀請

安排時間#

  • Sprint Review 是四個必要循環 Scrum 活動中最難排程的，因為包含 Scrum 團隊以外的人
  • 建議先確定關鍵利害關係人的偏好時間（如每隔兩週五下午 2:00），再據此安排其他 Sprint 活動
  • 使用固定週期可降低行政負擔並提高出席率
  • 一般不超過四小時的時間箱；常用規則：每 Sprint 週一小時

確認工作已完成#

  • Sprint Review 中只能展示已完成的工作——符合 Definition of Done 的項目
  • Product Owner 應在 Sprint Execution 期間進行即時審查，而非等到 Sprint Review 才第一次看到成果
  • 若 Product Owner 第一次在 Sprint Review 才看到成果，為時已晚——既來不及及時修正，也可能在利害關係人面前顯得與團隊不同調

Product Owner 在 Sprint Review 中拒絕或質疑工作，可能讓利害關係人感受到對立的「我們 vs. 他們」問題。Product Owner 與 Development Team 應作為統一的團隊出現在 Review 中。

準備展示#

  • 因為展示的都是已完成（潛在可交付）的工作，準備時間不需太多
  • 目標是提供透明度以便檢視與調適產品，而非精美的 Hollywood 製作
  • 大多數團隊的規則：每週 Sprint 時長不超過 30 分鐘到 1 小時的準備時間

決定角色分工#

  • 通常由 ScrumMaster 促進，Product Owner 開場歡迎利害關係人並提供 Sprint 結果概要
  • 建議讓每位 Development Team 成員都有機會在某次 Sprint Review 中親手展示

執行方式#

Figure 21.3: Sprint review activity

輸入與輸出#

  • 輸入：Sprint Backlog / Sprint Goal + 實際產出的潛在可交付產品增量
  • 輸出：已梳理的 Product Backlog + 更新的 Release Plan

總結（Summarize）#

由 Scrum 團隊成員（通常是 Product Owner）介紹：

  • Sprint Goal 與相關 PBI
  • 實際達成的產品增量概覽
  • Sprint 結果與 Sprint Goal 的對比

Sprint Review 應是一個無指責環境。如果目標未達成，所有參與者應避免追究責任，而是聚焦於「根據現況如何最佳地向前推進」。

展示（Demonstrate）#

Sprint Review 常被誤稱為「Sprint Demo」，但展示不是 Sprint Review 的目的：

  • 最重要的是參與者之間的深度對話與協作
  • 展示只是一種高效方式，圍繞具體事物激發對話
  • 讓利害關係人親自體驗（如試玩遊戲增量）有時更有效

如果沒有東西可展示怎麼辦？

  • 真的什麼都沒完成：聚焦於討論原因以及對後續工作的影響
  • 完成的工作難以展示（如純架構「膠水程式碼」）：至少可以用自動化測試來展示工作已完成。「難以展示」不是省略展示的合理藉口

討論（Discuss）#

  • 展示成為深度對話的焦點
  • 強烈鼓勵觀察、評論與合理討論
  • Sprint Review 不是深度問題解決的場合——那類工作應安排在另外的會議中

調適（Adapt）#

透過展示與討論，團隊得以回答關鍵問題：

  • 利害關係人喜歡看到的嗎？想要改變嗎？
  • 我們正在建構的東西在市場上仍然是好主意嗎？
  • 是否遺漏了重要功能？是否過度投資某功能？

這些問題的答案驅動 Product Backlog 梳理（新增、重新排序或刪除 PBI）與 Release Plan 更新（如調整範圍、日期或預算）。

flowchart TD
    A[Sprint Review\n展示與討論] --> B[收集利害關係人回饋]
    B --> C{需要調整?}
    C -->|是| D[梳理 Product Backlog]
    C -->|是| E[更新 Release Plan]
    C -->|否| F[維持現有方向]
    D --> G[下一個 Sprint Planning]
    E --> G
    F --> G

Sprint Review 讓我們有機會在仍然負擔得起的時候識別調適的方式——在每個 Sprint 結束時回應變化。

Sprint Review 常見問題#

簽核（Sign-offs）問題#

  • Sprint Review 不應是正式批准或簽核事件——PBI 在 Review 之前就應已被 Product Owner「批准」
  • 若資深利害關係人在 Review 中不同意某項工作已完成，該回饋有價值，但Product Owner 的決定仍應被尊重
  • 正確做法：建立新的 PBI 反映期望的行為變更，排入 Product Backlog 在未來 Sprint 處理

出席率低落（Sporadic Attendance）#

常見原因與對策：

  • 利害關係人事務繁重：這是組織失能的強烈訊號——同時進行太多工作導致無法履行承諾。建議停止較低優先級的產品開發
  • 不相信團隊能在短時間內產出值得審查的成果：最佳對策是實際建構出商業有價值的、潛在可交付的產品增量。當團隊做到這點，大多數人會認識到這些頻繁審查值得他們的時間

大型開發專案#

  • 多個高度相關的 Scrum 團隊可考慮聯合 Sprint Review
  • 優點：利害關係人只需出席一次；聚焦於已整合的成果而非獨立增量
  • 前提：所有團隊的 Definition of Done 必須包含整合測試
  • 缺點：時間可能更長，需要更大的會議室
Backward Sprint Execution Sprint Retrospective Forward