什麼是 Sprint Review：Scrum 中最容易被誤解的會議
Sprint Review（短衝檢視會議）是每個 Sprint 最後的成果展示與方向確認會議，目的是讓產品在每次迭代後，都能和利害關係人（Stakeholder）一起檢視進度、調整策略。
它不是功能驗收會議，也不是下對上的進度報告，它的精神更接近於開發團隊與用戶之間的「產品對話」。
定義與目的：展示成果、收集回饋、調整方向
這場會議的核心，就是把團隊這段時間做出的可運行產品增量（Increment）攤開，讓大家理解：
- 我們做到哪裡了。
- 真實成果長什麼樣。
- 利害關係人對方向有沒有新的想法。
- 要不要調整產品接下來的路線。
它的目的不是為了審查團隊做得好不好，是為了確認產品是否往正確的路上前進。
Sprint Review 與 Demo 的差別
Demo（展示、示範）大多是單向呈現，只是「給你看一下我們做了什麼」。
Sprint Review 則是雙向討論，透過情境式展示，得到利害關係人的回饋、提問與方向調整，最後整理回饋並更新回 Product Backlog（產品代辦清單）。
若 Review 只剩 Demo，就會少掉 Scrum 中最重要的透明（Transparency）、檢查（Inspection）與調整（Adaptation）能力。
Sprint Review 與 Retrospective 的差別
很多新手會把這兩個混在一起，但兩者的焦點完全不同：
- Sprint Review 的焦點是「產品」：成果、價值、方向、回饋。
- Retrospective 的焦點是「團隊」：合作、流程、問題、改善。
一個在看產品做得對不對，一個在看團隊做得好不好，兩者缺一不可。
Sprint Review 的核心是「價值確認」
Sprint Review 的本質很單純：
讓所有關鍵角色用真實的成果確認方向，用事實而不是想像來決定下一步。
能做到這點，才不會發生做到最後上線前才發生方向錯誤的慘劇。
The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.
— Scrum Guide（2020）
在真正的組織轉型初期，多數團隊（包括我過去的經驗）往往只能做到「檢視成果」，卻很難真正討論「未來方向」。
原因通常不在團隊本身，而是在外部利害關係人。
因為敏捷轉型通常只從一個小團隊出發，而對許多團隊外部的人來說，Review 自然就會被理解成「功能驗收會」。
一旦如此，討論焦點就會開始偏向「細節是否做對」、「情境有沒有處理乾淨」，而不是產品路線。接下來的行動也多半變成「下一個 Sprint 修掉這些缺陷」，而不是思考更上層的產品策略。
也因此，開頭才會說 Sprint Review 是 Scrum 中最容易被誤解的一場會議。
要讓 Review 真正發揮價值，兩個條件缺一不可：找到適任的利害關係人出席，以及有能力引導對話、不讓會議失焦的 Scrum Master。當這兩者就位，Review 才能從「Demo」成為它該有的樣子。
Sprint Review 的流程：從成果展示到未來方向的討論
Sprint Review 的重點不在於「報告做了什麼」，而是在於讓所有人用真實成果確認：這段 Sprint 的方向是不是走對了。
Sprint Review 的流程如果清楚，就不會流於形式，利害關係人也會更願意參加。
會議的時機點：發生在 Sprint 最後一天
Scrum 建議在每個 Sprint 的最後一天進行 Review。
這樣可以確保展示內容是最新、最完整的產品增量，也比較能讓大家把「這次迭代的成果」與「下一階段的方向」放在同一個討論框架裡。
會議的時間長度：依 Sprint 長度調整
時間不是硬性規定，但大方向可以用 Sprint 長度來判斷：
- Sprint 長度為 1 週：約 1 小時。
- Sprint 長度為 2 週：約 2 小時。
- 最長通常不超過 4 小時。
規定會議時間長度的目的不是為了拖長討論，而是要有足夠時間讓展示順暢、回饋完整，避免走向「快速帶過、大家都沒理解」的危險情況。
流程概覽：展示、討論、Product Backlog 更新、方向調整
多數團隊會使用以下順序，讓 Sprint Review 更有結構感：
- 回顧 Sprint Goal
先提醒大家這次 Sprint 的方向是什麼。 - 展示 Increment
展示真正可運行的成果。 - 回饋與討論
利害關係人提問、想法、對方向的建議。 - 更新 Product Backlog
Product Owner（PO）根據回饋調整排序和更新 Product Backlog Item（PBI）。 - 確認大方向
並非是在決定下個 Sprint 的內容，而是確認產品未來的走向。
這個順序能讓資訊累積得更有邏輯，討論也比較不會失焦。
展示 Increment 的原則：已驗收、可運行、可演示
展示不是秀技巧，而是讓大家看到「現在的產品長什麼樣」。
能在會議上展示的 Increment 應滿足三個基本原則：
- 已驗收：已經滿足完成的定義（Definition of Done, DoD）條件。
- 可運行：能點、能用，不是展示影片或原型。
- 可演示：最好用使用者實際使用的情境展示，這比逐條說明功能內容更好理解。
滿足了以上的基本原則，利害關係人才能給出真正有價值的回饋。
回饋與方向討論
這段討論通常會聚焦在：
- Increment 是否符合預期的使用情境？
- 有沒有看到新的使用者行為或市場變化？
- 哪些方向值得調整？
- 這些回饋要如何反映在 Product Backlog 上？
PO 會根據這些資訊更新 Backlog 的排序和內容，讓後續的 Sprint 更符合實際需求。
唯一目的就是對齊產品方向
Sprint Review 的流程看似簡單，但真正的價值在於：
每個人都能用實際上已完成的產品討論方向，而不是依靠想像尚不存在的功能。
討論越清楚，產品就越不容易走偏，而下一個 Sprint 的 Planning 自然也會順很多。
誰應該參加 Sprint Review：不只是 Scrum Team
一場有效的 Sprint Review，一定不能只有 Scrum Team 自己內部對話。
越接近使用者、越接近商業的人越要出席，回饋才會真實。
Review 的目的是對齊方向，如果關鍵角色缺席，整場會議自然也就失去判斷價值的基礎。
Product Owner 的責任：講清楚「我們為什麼做、做到哪裡了」
PO 在 Review 裡的角色不是「主持人」，而是「產品解說員」，幫大家把這次 Sprint 的脈絡講清楚，包括：
- 本次 Sprint Goal 是什麼。
- 做了哪些 Increment。
- 功能背後的使用場景或商業理由。
PO 也需要負責引導回饋，把利害關係人的意見轉成後續可以採取的方向。
Scrum Master 的角色
Scrum Master 的任務不是「操作電腦展示」，也不是在旁邊做會議記錄，而是：
- 保持會議在正軌上。
- 協助各方維持正常溝通。
- 處理現場可能的誤解或拉扯。
- 讓回饋能夠聚焦在產品，而不是個人。
簡單講，就是讓 Review 變成「真正的產品對話空間」。
Development Team 的任務
開發團隊不只是展示系統功能畫面，更是展示「真實的產品狀態」。他們需要能講清楚：
- 這次迭代做了什麼。
- 現在能做到什麼。
- 現況有哪些限制。
- 過程中有哪些關鍵發現。
當利害關係人提出技術相關或使用情境的問題，開發團隊也能直接回答，讓資訊不會因為轉述扭曲或誤解。
Stakeholder 的參與方式
利害關係人（Stakeholder）的存在是 Sprint Review 能不能「有價值」的關鍵。
他們可能是：
- 業務人員。
- 客服或營運人員。
- 使用者或顧客代表。
- 合規或法務。
- 市場、策略專家或管理層。
他們的回饋能補足 Scrum Team 看不到的視角，讓產品更貼近真實需求。
好的 Review，不是工程師單方面展示，而是利害關係人會感覺自己「真的有參與產品方向」。
Review 是跨角色對話
Sprint Review 如果只有 Scrum Team 出席，就會變成一場自說自話的會議。
真正的 Review 需要各種角色一起確認產品價值，才能讓方向不斷被校準。
多方參與，是 Review 之所以能檢查與調整的核心。
Sprint Review 要展示什麼？
Sprint Review 的核心，就是「展示真實可用的產品」。
如果展示內容是 PPT、流程圖、或半成品原型，利害關係人很難給出真正有意義的回饋，整場 Review 也會淪為形式主義。
要讓這場會議真的有用，展示的內容必須圍繞一件事：真實的 Increment。
可運行的 Increment
Increment（產品增量）必須是已通過 DoD 的可用成果，要能讓人可以實際操作。
不論規模大小，只要是本次 Sprint 完成能運作的功能，都應該在會議中展示。
這能讓利害關係人以「實際使用者」的角度理解成果，而不是依賴自己的想像能力。
洞察、風險與發現
Review 的展示不只功能，也包含這次迭代的學習：
- 使用者行為的新洞察。
- 技術上的新限制。
- 被驗證的風險或假設。
- 數據上觀察到的趨勢。
這些資訊有助於利害關係人判斷接下來的方向，並理解為什麼某些功能做成這樣。
商業或使用數據（若適用）
如果產品已經上線或有「先期使用者」試用，展示「使用數據」會比展示「功能」更有價值，例如：
- 使用量的變化。
- 完成率、轉換率的差異。
- Bug 的下降量。
- 客訴或客服開單的趨勢。
數據能避免討論變成主觀辯論，也能讓 PO 的決策更有依據。
展示重點是「真實產品」
好的 Sprint Review，不需要華麗簡報，也不需要複雜流程。
重點是讓所有人看到「產品實際的樣子」，並基於真實成果討論下一步。
能被看到、被操作、被提問的 Increment 才是 Review 的主角。
Sprint Review Bazaar：用市集方式展示成果的替代流程
在大型組織或跨多團隊的環境裡，傳統一場 Sprint Review 常常會變得又長又悶。經過多個開發團隊輪流展示轟炸後，利害關係人聽到後面其實已經沒力氣吸收。
為了讓回饋更有效率，一種更彈性、也更人性化的形式逐漸流行起來：Sprint Review Bazaar（短衝檢視市集）。
它的概念很像逛市集，由各團隊各自擺攤，而利害關係人則自由在攤位間走動、自由提問、自由回饋。
這樣做的資訊密度和品質更高，也更能讓利害關係人把注意力放在真正有興趣的成果上。
Review Bazaar 的概念與適用場景
Bazaar 的核心特點是「多攤位、自由走訪」，適合以下情況：
- 多團隊同步整合同一個產品。
- 利害關係人眾多、角色多元。
- 成果種類多元。（功能、研究、原型、改善）
- 傳統 Review 容易塞車或變成 PPT 報告大會。
這個形式能讓每位利害關係人只花時間在自己關心的區域，也讓討論更深入。
市集式流程：多攤位展示、Stakeholder 自由走訪
Sprint Review Bazaar 整體流程大致如下：
- 開場 5 分鐘
PO 或代表快速說明整體方向與重點成果。 - 攤位展示時間
各團隊在不同位置擺攤，展示自己的 Increment。 - 自由走訪
利害關係人依興趣自由選擇攤位觀看成果，並且提問和回饋。 - 攤位輪替（可選）
若攤位數量眾多，可以安排讓利害關係人在固定時間一起更換攤位。 - 收斂與整合
PO 蒐集所有攤位回饋，整理後反映到 Product Backlog。
市集的方式能降低參與者的疲勞度，也讓交流變得更自然。
如何整合回饋：收集、歸類、轉成 Product Backlog
Bazaar 最大的挑戰不是展示，而是回饋整合。PO 通常需要：
- 收集來自各攤位的回饋。
- 依主題分類。（價值、風險、問題、機會）
- 找出共通需求與重大洞察。
- 分析哪些回饋需要調整 Product Backlog。
- 與團隊討論排序與策略影響。
這樣整理後，產品方向會比傳統 Review 更全面，也更貼近真實需求。
Bazaar 讓大規模組織更容易吸收回饋
Sprint Review Bazaar 不會取代傳統 Review，而是另一個更適合多團隊、多人參與的方式。
它讓展示更輕鬆、讓討論更深入、讓回饋更具體。
越多角色願意真的「站在產品前」互動，產品方向自然就會越清楚。
常見錯誤：為什麼 Sprint Review 常常失焦？
Sprint Review 本來應該是一場「用成果檢查方向」的會議，但在很多團隊裡，它往往變成形式主義，只會照著流程走，但誰都沒有真的在討論產品。
要讓 Review 發揮作用，理解這些常見錯誤是第一步。
錯誤 1：變成成果報告會議，光講簡報不展示產品
很多 Review 開到後面只剩下播放 PPT：
團隊先報告進度，再講做了哪些事，然後照著投影片唸一堆實作細節。
真正的 Increment 卻沒有展示，沒人看到。利害關係人只能聽描述想像而不是看到「實際產品」。
這讓回饋失真，方向自然也對不準。
錯誤 2：Product Owner 沒準備，連成果的脈絡都講不清楚
有些 PO 上場時才第一次看到 Increment 實際怎麼運作，導致展示時講不出「為什麼要做」，無法串起這次 Sprint 的故事，也無法正確引導回饋。
Review 缺乏脈絡時，利害關係人提的問題通常也會失焦，最後討論發散，得不到有意義的回饋。
錯誤 3：只展示功能，不討論「價值」
很多團隊在 Review 時只展示功能的操作，卻沒有講清楚它到底解決了什麼問題、使用者會如何使用、在哪些情境下最能產生價值，以及它在商業或策略上具備什麼意義。
當這些價值脈絡都缺席時，Review 就只剩下「看畫面」，對方向的理解自然也會越看越模糊。
錯誤 4：Stakeholder 被當成旁觀者
利害關係人（Stakeholder）常常只是坐在那裡聽完簡報，既沒有提出意見，也沒有被引導參與討論。
結果就是回饋不足、方向得不到驗證，整場 Review 最後淪為單向報告。
如果利害關係人沒有參與感，就不會提供那些至關重要的資訊，而產品也因此失去寶貴的校正機會。
錯誤 5：Review 變成驗收會或審查會
這是 Sprint Review 最常見、也最具破壞性的反模式。會議一旦開始出現：
- 逐條檢查功能。
- 挑出哪些地方「還沒做完」。
- 針對實作細節審查工程師。
- 明顯帶有「挑錯誤」的氣氛。
整場就會直接從「討論產品方向」掉進「審查任務品質」。
最根本的原因，往往是：展示前沒有確認 Increment 是否通過 DoD（Definition of Done）。
DoD 如果沒有在事前檢驗，就會變成：
Review 當場才發現功能不完整，讓利害關係人面對的是半成品，工程師不斷被追問「這怎麼還沒好？」，PO 也說不清楚這次的成果到底算不算完成。
氣氛在這種情況下自然開始緊繃，方向性的討論更是完全展開不了。
Review 的主角是「已完成的增量」，只要把 DoD 的確認放在展示之前，就能避免 Review 被迫變成「驗收大會」。
Review 若沒有價值討論就失去意義
Sprint Review 若失焦，通常不是流程問題，而是焦點跑掉。
做好核心步驟：展示成果、了解價值、討論方向、更新策略。
只要少掉其中任一步，Review 就會退化成形式主義。
要讓它真正有作用，關鍵是把注意力重新放回產品本身，而不是報告流程。
高品質 Sprint Review 的做法
一場好的 Sprint Review，不是講得多完整，而是讓所有人用最短的時間理解「我們做了什麼、為什麼這樣做、接下來該往哪裡走」。
以下這些做法能讓 Review 的資訊密度和品質提高，也更容易得到有用的回饋。
做法 1：簡單清楚的議程，讓大家知道會議要往哪裡走
高品質的 Review 不會冗長，也不是隨興想講什麼就講什麼。通常會有一個固定、好記的流程，例如：
- 回顧 Sprint Goal。
- 展示 Increment。
- 討論回饋。
- Product Backlog 更新與方向確認。
這樣的議程能讓參與者更快進入狀況，避免走向閒聊或技術細節。
做法 2：以使用者情境展示，比逐條說明功能更好理解
展示時不需要逐項功能照單唸。最有效的方式是用「一個具體的使用者流程」帶著大家走過使用情境。
這能讓利害關係人更清楚功能實際會怎麼被使用、是否符合預期情境，以及哪些操作或流程仍讓人感到不直覺。
情境式展示比「功能導覽」更能激發回饋。
做法 3：一句話講清 Sprint Goal，為展示建立共同焦點
展示前，PO 先用一句話快速重申 Sprint Goal，可以讓整場 Review 的焦點變得更明確。
例如：
- 「這次 Sprint 要解決的是登入流程過慢的問題。」
- 「這次 Sprint 的核心是提供查詢結果的基本版。」
有方向，討論才容易聚焦。
做法 4：回饋整理與 Backlog 更新，不只光聽，還要讓它發生
高品質的 Review 不只是把回饋收集起來，而是要進一步將相似的意見歸類，找出其中最重要的洞察，並根據新的資訊調整 Product Backlog 的排序，同時向團隊說明下一步預計前進的方向。
利害關係人看見回饋能真的影響產品的方向時，參與意願自然會提升。
Review 是改善產品，不是驗收產品
高品質的 Review 會讓所有參與者都覺得自己看見了真實的產品、理解了具有意義的背景脈絡，也感受到自己提出的回饋確實能影響接下來的產品方向。
當 Review 能用成果對齊方向，敏捷的核心精神：透明、檢查、調整，就會自然浮現。
實務常見迷思：為什麼 Review 在公司裡常常不起作用？
很多團隊都有 Sprint Review，但真正能發揮效果的卻不多。
會議形式保留了，可是它原本的意義：「用成果檢查方向、用回饋調整策略」卻常常在組織文化裡消失無蹤。
下面這些迷思非常常見，也直接決定了 Review 到底有沒有價值。
迷思 1：Stakeholder 缺席，最該參加的人沒有出現
Sprint Review 最大的價值是「跨角色對話」。
但在不少企業裡，利害關係人不來，原因通常是：
- 他們以為這只是工程師自嗨的 Demo。
- 不知道自己應該提供什麼回饋。
- 過往來了也沒什麼貢獻感。
結果就是：
工程師在台上展示，真正能決定方向的人卻不在場，Review 自然就淪為形式。
迷思 2：Review 被當成形式主義：只要完成流程就好
有些公司把 Review 視為 Scrum 的規定之一：「反正流程就是要照著跑」。
於是整場 Review 就變成走過場的展示，大家一邊聽一邊忙著處理自己的工作，而收到的回饋也完全不會進入 Backlog，最終失去討論與校正方向的意義。
只要內部文化把 Review 當「例行報告」，它就不會有任何決策價值。
迷思 3：缺乏產品思維：Review 變成「做了什麼」而不是「做成什麼」
沒有產品觀的團隊，往往會把 Review 弄成一場「進度報告」，只是在說明做了多少、解釋技術細節，或介紹功能規格本身。
但 Review 的重點其實在於弄清楚這個成果真正解決了什麼問題、使用者實際會怎麼使用，以及在聽完回饋之後，產品方向是否需要調整。
當只在意「做了什麼」，團隊就很難討論真正的價值。
迷思 4：缺乏 DoD，導致無法展示真正可用的 Increment
許多公司之所以做不到高品質展示，其實原因很簡單：功能到了 Review 時往往還沒真正完成。
於是只好硬著頭皮展示半成品，Live Demo 動不動就卡住，利害關係人看到的也不是可用的增量而是測試版，甚至只是臨時拼湊的展示用版本，自然無法讓人專注在價值與方向上。
沒有 DoD（Definition of Done），Review 很容易變成驗收會或找問題大會，討論也就很難聚焦方向。
沒有回饋，敏捷自然也不會存在
Review 在企業裡會被弱化，多半不是團隊不努力，而是環境不支持：
- 沒回饋。
- 沒討論。
- 沒方向調整。
- 沒依回饋更新 Product Backlog。
少了這些，敏捷就只剩表面上的儀式，失去了檢查與調整的能力。
要讓 Sprint Review 重回正軌，團隊必須把它視為「產品決策會議」而不是「展示會議」。
如何衡量 Sprint Review 的品質？五個指標
Sprint Review 要不要開得好，其實現場的氣氛與討論深度就能看出端倪。
品質不需要靠複雜量表來評分，只要從幾個具體行為觀察，就能判斷這場 Review 真的有在檢查方向，還是只是在走個過場。
指標 1：討論與提問比例
Review 如果只有 PO 在講、工程師在示範，而利害關係人全程一句話都沒說，通常代表展示的內容本身不夠吸引人，他們也不清楚自己應該回饋什麼，加上流程設計從頭到尾就沒有真正打算讓他們參與，自然只能成為旁觀者。
高品質的 Review，利害關係人會主動問問題。只要問題變多，就代表參與度提高。
指標 2：回饋有無反映到 Backlog 的更新
如果所有回饋最後都沒被整理、沒被採納、沒影響下一步的方向，那 Review 的過程再精彩也沒有意義。
品質好的 Review 會讓人清楚看到 PO 如何整理並總結回饋。這些回饋會被分類、轉換成具體的 PBI，並且進一步影響 Backlog 的排序，讓產品方向因為回饋而真正更新。
當 Backlog 開始因 Review 而改變，才表示這場會議真的產生影響力。
指標 3：產品方向是否越來越清楚
糟糕的 Review 開完後，團隊往往比之前更混亂：大家不確定產品接下來到底要往哪個方向走，利害關係人的意見彼此矛盾，而 PO 也說不出清楚的下一步，讓方向迷失在茫茫大霧中。
反過來說，高品質的 Review 會讓團隊更清楚目前的產品位置、接下來階段的策略方向，以及哪些事項需要優先探索或改善，讓後續的迭代更有意義也更有方向感。
方向清晰，是高品質 Review 最直觀的成果。
指標 4：展示貼近使用者情境的程度
如果展示只是技術導覽、介面介紹，利害關係人很難看到真正的價值。
而 Review 的品質，往往會反映在展示方式的演化上：介紹不再只是功能本身，而是從使用者故事切入。展示不再是零散的單點，而是能呈現連續的使用者情境流程。講述方式也逐漸從工程語言轉成讓非技術角色也能輕鬆理解的語言。
展示越貼近真實使用者情境，回饋就越有效。
指標 5：跨部門對話增加
一場高品質的 Review 現場，對話會是「橫向交流」而不是開發團隊對利害關係人的「單向報告」。
業務會提供市場最新的變化，客服會分享近期用戶的行為與反饋，法務會提醒可能的風險與合規議題，工程師則會補充技術上的可行性與限制。整場討論像是共同對齊方向，而不是被動看簡報。
這些「跨邊界的對話」越多，Review 的價值越高。
好的 Review 會讓下一個 Sprint 容易很多
衡量 Sprint Review 品質最簡單的方法，就是問自己：
「這場 Review 讓我們更知道下一步該怎麼走嗎？」
如果答案是肯定的，那這場 Review 就是有效的。如果不是，那就是改善流程的信號。
高品質 Review 的目的並不是為了表面上的展示成果，而是用真實成果校準方向，讓下一個 Sprint 更穩、更清楚。
結語：Sprint Review 的價值是讓產品持續修正軌道
Sprint Review 的核心價值，其實一直都不是展示，而是透過展示換來「更接近真實的方向判斷」。
產品在市場上不會照著原計劃走，使用者的行為也常常和一開始的假設不同。如果沒有定期檢查與調整，產品自然會越做越偏。
Review 就像產品的導航系統：每次展示一小段 Increment，就是在確認「現在的位置在哪裡」，而利害關係人的回饋則是「這條路是否仍然值得走」。
方向調整得越頻繁、越及時，產品走錯路的成本就越低。
更重要的是，Sprint Review 不是團隊的單人表演，而是一場跨角色、跨視角的產品對話。
只有當工程、業務、營運、客服、商業策略等不同觀點碰撞在一起，產品才會真正貼近使用者與市場。
如果 Review 做得扎實，整個產品開發會變得方向更明確、決策更有依據、風險更早被揭露。
而團隊對「為什麼做」的理解也會比「做了什麼」更加清楚，讓每一次迭代都真正推著產品往前進。
敏捷不是為了跑流程，而是為了不斷校準。
而 Sprint Review，就是讓產品維持在正確軌道上，最重要的對話。
只要願意透過真實成果檢查方向、並依回饋調整策略，產品開發才能持續校準軌道。
