經過了 2 星期的開發衝剌（Sprint 通常介於 2-4 週，不同專案、公司可能有所不同），在 Sprint 即將結束的當天，Scrum Master 會舉行衝剌審視會議，做為一個 Sprint 的收尾。

衝剌審視會議目的

衝剌審視會議（Sprint Review Meeting），這個會議的目的是為了讓開發團隊能將一個 Sprint 努力開發出來的成果，一方面展示出來，另一方面鼓舞士氣，並且成果也能夠讓產品負責人（PO）檢視驗收，藉此順便獲得 PO 的回饋，讓團隊得已知道是否需要再做調整。

除了產品負責人外，Scrum Master 也可邀請相關的利害關係人一起參加，例如出資者、外部客戶、產品行銷、使用者代表等。

衝剌審視會議重點項目

邀請會議前，需確保每個人與會者都了解這個會議的目的是在看成果、給具體的回饋建議，而不是腦力激盪或行政會議。

會議之前

(我們團隊習慣是前一天) Scrum Master 與開發團隊需一同確認要展示哪些工作項目、怎麼展示、在什麼環境展示、有沒有什麼事得先「預處理」才能打通，例如需創建大量資料進 Stage 環境。亦或有些項目還沒處理完，需要以 Workaround 方式繞開才能展示。

若 Scrum Master 沒安排這個環節，到時就直接讓團隊上場，通常都會遇到很多問題。
沒有先演練就上場之莫非定律小劇場：

場景 1 (前一天的 Stand-up)

資深工程師趙哥：「這小 Bug ，改一下就沒問題了 ，妥妥的」→ 結果隔天 Demo 當下才發現忘了改。

場景 2 (當天 Demo 現場，系統出錯)

工程師小蔡：「誒誒奇怪，之前不是都好好的嗎 」→ 結果全會議的眼睛盯著他開 IDE，冒冷汗邊找原因邊想辦法排除。好心的 Scrum Master 趕緊站出來講冷笑話，試圖轉移焦點，幫他爭取時間。

所以我的建議是 Scrum Master 最好要求團隊視同正式 Review 做 Rehearsal，雖然這會花一些時間，但一場好的 Review 結果，也能讓團隊士氣大增，因此絕對值得。

有朋友可能會說，這樣不是很花時間嗎？ Rson 建議相對成熟的團隊，可以簡化成：在 Rehearsal 時討論好要 Demo 什麼以及展示的流程即可，而負責 Demo 的人，在確保相關的環境都沒問題後，需在腦海中真的「將整個 Demo 的流程細節過一遍」，就像經典日劇「醫龍」男主角龍太郎每次手術前，都會在腦海中演練那樣

圖片來源：<醫龍>

會議當天

會議開始 opening，Scrum Master 說明這次的衝剌待辦清單，哪些項目已完成、哪些還在進行中。接著，團隊開始向大家一一展示成果，並說明這將能為產品帶來什麼價值。

展示完後，收集所有參與者所做的回饋與想法，並決定哪些要在 Release 前修改。

會議結束後

Scrum Master 引導產品負責人與開發團隊討論出哪些成品增量要上，以及上線發佈的日期時間。

一些小提醒

在 Demo 的時候，需針對的是端到端（End to End）的使用者故事，而不是技術上如何實現的細節。也就是說，得講麻瓜聽的懂的話，而不是工程語言。

圖片來源：<讓子彈飛>

每進入一個新功能要展示的時候，建議稍微再唸出使用者故事的描述句，讓大家比較會把自己代入「該用戶」的角色中，盡量避免由「自己」這個角色出發，可能會給予了不洽當的回饋，比如說「如果是我我不會這樣這樣用」、「應該要 OOO 這樣，使用者體驗才正確 」。

更甚者，若這個給建議的對象是 HIPPO，很容易在他無意中下了強指導棋，團隊就會因此把產品做成他想要的樣子，而不見得是真正的用戶需要的樣子。Sprint Review 在 Demo 每個功能前，如果能先提一下使用者故事陳述句，無形中可以提醒大家要記得換位思考，個人認為這點在做垂直領域的產品開發時，尤其重要。

呼！今天差點就斷更了，沒有存糧，果真危機重重。各位鐵人賽的邦友們一起努力撐下去！